Static Classes bei ApplicationServer start (Tomcat) initialisieren

[bemar]

Hallo,

ich möchte ein paar statische Klassen, auf die von allen Sessions drauf zugegriffen werden kann, beim Serverstart initialisieren. Wie ist das möglich? Gibt es eine Art >Startup< Methode beim Tomcat bzw. WebApp Servern?
Bisher lade ich die Klassen beim ersten Connect in meinem Controller Servlet. Diese Lösung empfinde ich aber nur als Notlösung. Gehts auch eleganter?

Danke für eure Tipps

Gruß

Ben

 

[Oliver Gierke]

Es gibt soweit ich weiß ein <load-on-stratup /> element oder soetwas ähnliches. Dann wird init() direkt beim instantiieren aufgerufen und nicht erst beim ersten Zugriff.

Allerdings klingt das, was du da vorhast schon arg nach Vergewaltigung:

ein paar statische Klassen, auf die von allen Sessions drauf zugegriffen werden kann

*grusel

REINHAUN!

 

[bemar]

Nicht rummaulen sondern konstruktive Vorschläge bitte:

Wie sonst verwalte ich den Zentralen Zugriff auf die Logfiles, das ConfigFile und die Datenbank?

 

[Oliver Gierke]

Es gibt soweit ich weiß ein <load-on-stratup /> element oder soetwas ähnliches. Dann wird init() direkt beim instantiieren aufgerufen und nicht erst beim ersten Zugriff.

Konstruktiv und dazu noch konkret. Noch was konkretes: globale Variablen, statische Klassen, selbstprogrammierte Singletonzugriffe sind Antipatterns. Ansonsten sollte unser aller Freund Google beim Stichwort "Dependency Injection" etwas Information liefern.

Für "richtige" Tipps müsste man halt mehr Details Erfahren. "Zentraler Zugriff auf ... die Datenbank" ist hoffentlich nicht dein Ernst. Ich fände es gefährlich, wenn jede Klasse (womöglich auch noch das Frontend) der Anwendung potentiell Zugriff auf die Datenbank hätte. "Data Access Object" ist in dem Fall das Pattern, was hier weiterhilft.

Logfiles und ConfigFiles sind halt recht wolkige Begriffe. Da kann man ohne Details halt nicht mehr sagen, ausser "globaler Zugriff ist keine Gute Idee".

REINHAUN!

 

[bemar]

Dann werd ich etwas konkreter.

Im ConfigFile steht für jeden Teilbereich der Anwendung etwas drin. Für die zentrale Datenbankklasse z.B. die ganzen Connect-Infos. Für die Logfileklasse wie gross das Logfile ist, welche Logfiles welchen loglevel wegschreiben usw.
Daher benötigt jede Komponente zumindest beim Init einen Zugriff auf das ConfigFile, in dem alles drin steht.

Natürlich hat das Frontend (JSP) keinen Zugriff auf die Datenbank. Zumindest nicht in der Form, das in der JSP ein Select statement steht. Ist alles schön gekapselt. Jedoch brauch ich Zugriff in der Form, das ich Checkboxen, DropDownMenus etc, mit Werten fülle. Das mach ich aber über spezielle Klassen, von denen ich mir ein fertig gefülltes HTML Element (z.B. Checkbox) liefern lasse.

Ich schau mir jetzt mal die DesignPatterns an. Ich trau mich aber fast wetten, das da ähnlich gemacht wird. Das ganze heißt halt dann EJB, Struts und was weiß ich noch alles.

 

[Oliver Gierke]

Die Frage ist halt, warum du sowas alles selber handlen bzw programmieren willst. Logs kannst du über die gängigen Logframeworks konfigurieren. Datenbanken würde ich auch nie eine Komponente aktiv selber konfigurieren lassen. Für sowas gibt es Dependency Injection. Die Komponente sollte nicht selbst ihre umgebung Konfigurieren, sondern Dependencies von einem Container hereingereicht bekommen. Warum? Da: http://www.martinfowler.com/articles/injection.html

REINHAUN!

 

[karatekid0815]

Hi bemar,

das was du machen willst, macht man im allg. mit Singleton. Zumindest beim Tomcat kann man das so machen. Die Initialisierung erfolgt beim ersten Zugriff auf die Klasse.

Im Moment scheint zwar "Dependency Injection" das Allheilmittel für alles und jedes zu sein, allerdings hat auch das seine Grenzen hinsichtlich Aufwand/Nutzen und Übersichtlichkeit. Außerdem, wenn man sich mal die Dependency Injection Lösungen genauer anschaut machen die es auch nicht anders. Dadurch wird es nur gekapselt.

Beim Thema Logs kann ich MSProductions zustimmen. Erfinde das Rad nicht neu.

 

[Oliver Gierke]

Im Moment scheint zwar "Dependency Injection" das Allheilmittel für alles und jedes zu sein, allerdings hat auch das seine Grenzen hinsichtlich Aufwand/Nutzen und Übersichtlichkeit.

Das musst du mir erklären. Dependency Injection SCHAFFT Übersichtlichkeit. Wie oft habe ich mich in legacy Anwendungen durch Klassen gewühlt, die durch irgendwelche Propertyfiles Parameter laden, oder gar den Klassennamen für eine Instanz daraus ausgelesen haben (generische Factory). Da rollen sich mir die Fußnägel hoch. Was ist bitte an einem Konstruktorparameter oder einem Setter für eine Depenency unübersichtlich? Dadurch wird die Dependency erst sichtbar.

Deine Aussage macht eigentlich nur Sinn, wenn man DI mit nem DI Container verwechselt. Die Konfiguration desselben kann unter Umständen unübersichtlich werden, wenn man darin ungeübt ist - aber wo ist das nicht so?

Gruß
Ollie

P.S.: dass ein Singleton in der allgemeinen Einsatzweise mittlerweile Antipattern ist, weißt du, oder?

 

[Thomas Darimont]

Hallo,

P.S.: dass ein Singleton in der allgemeinen Einsatzweise mittlerweile Antipattern ist, weißt du, oder?

Ich denke du meinst eher, das die geläufige Implementierung des programmatischen Singleton Patterns in Java mittlerweile als Anti-pattern angesehen wird:

/**
 * 
 */
package de.tutorials;

public class Singleton {
    private static Singleton instance = new Singleton();

    private Singleton(){
        
    }
    
    public static Singleton getInstance() {
        return instance;
    }
}

Das Singleton Konzept an sich ist jedoch nach wie vor ein wichtiges und notwendiges Konstrukt. Die neue "Lehre" sagt jedoch das man die Objekte die als "Singletons" auftreten sollen von einem Container als solche behandelt und nach aussen repräsentiert werden.

Gruß Tom

 

[Oliver Gierke]

Genau das meinte ich mit "allgemein (verbreitete) Einsatzweise". Es ist spannend wie viele Probleme von legacy Software von schlechten Singletonimplementierunge herrühren. und 90% der Entwickler meinen mit "das macht man besser mit Singleton" immer noch die "von Hand Implementierung" des Patterns. Dafür ist - wie du schon sagst - der Container zuständig. Jede manuelles Implementierung ist eigentlich eine Verletzung des SoC wie ein Dependency Lookup z.B.

Gruß
Ollie