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

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!

Nicht rummaulen sondern konstruktive Vorschläge bitte:

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

Zitat von MSProductions

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!

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.

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!

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.

Zitat von karatekid0815

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?

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:

Code java:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

/**  *  */ 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

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

Zitat von MSProductions

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).

Hi Olli,

genau mit diesen "Totschlagsargument" kann ich dir auch kommen.......

Wie oft habe ich mich in Anwendungen durch Klassen gewühlt, bis an Stellen wo dann Properties durch DI gesetzt wurden. Dann wühlte ich mich durch irgendwelche Propertyfiles die wiederum auf weitere Propertyfiles verwiesen, in denen dann Ausdrücke ausgewertet wurden, um dann letztendlich irgendwo den zugewiesenen Wert zu finden.

Und ich habe bereits Projekte erlebt wo das so gehandhabt wurde.

Um das noch mal klarzustellen. Ich habe ja nix gegen DI. Nur man muss es wie alles sinnvoll einsetzten. Wie eben das Singleton Pattern auch.

Gruß KK

Ja aber Moment, das fußt dann wieder auf 2 IMHO falschen Annahmen:

1. DI selbst sagt dir nicht, welcher Wert verwendet wird. DI legt die Dependency zu einer anderen Klasse oder einem Wert offen. Welcher Wert da zur Laufzeit drinsteht, ist über die Konfiguration ersichtlich, was uns zu Punkt 2 führt.

2.

Zitat von karatekid0815

Wie oft habe ich mich in Anwendungen durch Klassen gewühlt, bis an Stellen wo dann Properties durch DI gesetzt wurden. Dann wühlte ich mich durch irgendwelche Propertyfiles die wiederum auf weitere Propertyfiles verwiesen, in denen dann Ausdrücke ausgewertet wurden, um dann letztendlich irgendwo den zugewiesenen Wert zu finden.

Genau das meinte ich mit "ungeübten Umgang mit dem Container". Konfigurationsfiles kann man sinnvoll aufteilen, deklarative Namen geben usw. man kann sie natürlich auch unheimlich lang werden lassen, unsprechende Beziehungen aufbauen und ähnliches. Dennoch ist die Konfiguration zentral und nicht über den ganzen Classpath verteilt. Desweiteren gibt es im Falle von Spring hervorragenden Toolsupport, den ich bei Class.newInstance(fooBar); einfach nicht habe...

Kurz, DI ist ein Mittel Konfiguration klarer sichtbar zu machen. Dass ich eine Technologie auch umständlich (vielleicht sogar falsch) einsetzen kann ist klar, aber doch nur bedingt Schuld der Technologie, oder?

Gruß
Ollie

Hallo,

hier ist es dann nur eine Frage des entsprechenden Tool-Supports um der schar an Konfigurationselementen und Konfigurationsdateien Herr zu werden.

Verwendet man Spring leistet die Spring IDE (für Java) genau bei diesem Thema hervorragende Dienste. Neben vielen weiteren netten helferelein kann man sich damit die gesamte Konfiguration oder Auszüge daraus als Graph visualisieren lassen. Zusätzlich hat man die Möglichkeit zu sehen welches Objekt welche anderen Objekte / Werte referenziert / injeziert bekommt. Weiterhin kann man sich eigene Konfigurationssets (auch Projektübergreifend) Konfigurieren mit denen man die zuvor genannte partielle Sicht auf den Objekt Konfigurations Graphen erzeugen kann.

Ohne einen solchen Toolsupport wirds bei größeren Projekten wirds aufgrund der Menge an Konfigurierten / Zusammengesteckten Objekten wirklich schwierig, bzw. unübersichtlich... das merkt jeder der Spring.Net in größeren .Net Projekten verwendet... aber auch da ist Land in sicht

Gruß Tom

Wieso 2 falschen Annahmen ? Punkt 1 sagst du das was ich auch meinte bzw. geschrieben habe und Punkt 2 ist keine falsche Annahme sondern selbst erlebt. Insofern liegen wir da ja nicht auseinander.

Eine Frage zum hervorragenden Spring - Toolsupport. Ich habe noch keinen gefunden. Das Eclipse Plugin ist eher mager. Was nimmst du bzw. welchen kannst du empfehlen ?


edit... Tom war schneller... Spring IDE ? Ok, das Projekt ist jetzt schon ne Weile her. Hat sich da so viel getan ? Muss ich mir dann gleich mal anschauen. Ändert das Plugin jetzt auch automatisch die Ausdrücke ab bzw. checkt die Abhängigkeiten ?

Ich meinte falsche Annahme, weil DI alleine nicht das leistet, was du mit deinem Kritikpunkt angesprochen hast. DI sorgt nicht dafür, dass du weiß, mit welchem Wert zur Laufzeit gearbeitet wird. DI leistet, dass du an der Klassenschnittstelle erkennst, dass die Klasse eine Property benötigt oder eine andere Klasse. Das siehst du im Fall von manuellen Dependency Lookups oder dem selber Einlesen von Konfigfiles eben nicht.

Der zweite Punkt ist der, dass du ein Problem darlegst, was durch ungeübten Umgang mit dem Container entsteht. Das hat doch aber nichts mit DI an sich zu tun...

Die Spring IDE ist doch sehr hilfreich. Woran hängts denn? Ich hab hier momentan ein Projekt dass aus 20 Eclipse Projekten besteht. Ohne die Codecompletion in den Configfiles, den Beangraph und die Visualisierung von Pointcuts wär das sicher arg unübersichtlich. Fragen wir mal andersrum - wo hättest du denn gern mehr Unterstützung?

Gruß
Ollie

PS: Nette Diskussion übrigens, wenn auch etwas Offtopic