Static Classes bei ApplicationServer start (Tomcat) initialisieren

MSProductions hat gesagt.:
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).
Zum Vergrößern anklicken....
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.

karatekid0815 hat gesagt.:
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. ;-] ;)
Zum Vergrößern anklicken....

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 ?
 
Zuletzt bearbeitet:
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 ;)
 
Was ich mir bei diesem Projekt damals gewünscht hätte, ist z.B. automatische Kompletierung bzw. Unterstützung der Kompletierung. z.B. das eine Änderung im Configfile im Code mitgeschrieben wird bzw. zumindest darauf verwiesen wird. Wir mussten den Code und die Configfiles immer von Hand konsistent halten. Und Tipfehler sind schnell gemacht. Eine grafische Übersicht gab es auch nicht. Das Plugin bot einen Check der Abhängigkeiten der sehr bugy war. D.h. es wurden manchmal Fehler anzeigt die es nicht gab und echte Fehler bemerkte man erst zur Laufzeit. Auch die Auflösung über mehrere Config Files hinweg wäre ein schönes Feature gewesen.

Das ist das was mir spontan einfällt. Wie gesagt, es ist schon eine Weile her.
 
Muss eine ganze Weile her sein, um ehr lich zu sein. Weil die Dinge, die du ansprichst schon seit langem tun. Mehrere Configfiles kann man mit ConfigSets gruppieren, der Configeditor bietet bei <property /> Elementen sogar nur properties an, für die in der entsprechenden Klasse Setter existieren. Sehr hilfreich ist auch das Aufzeigen von Pointcuts, d.h. Wenn du einen Pointcut definierst, werden automatisch alle Klassen bzw. Methoden markiert, die von dem Pointcut "getroffen" werden, inkl. einer Rückreferenz auf den "treffenden" Pointcut... Erleichtert das Arbeiten AOP ungemein...

Gruß
Ollie
 
na ja, war Anfang diesen Jahres. Allerdings kann das Plugin älter gewesen sein. In größeren Firmen bekommt man ja seine Umgebung genauestens vorgeschrieben was zum Teil auch verständlich ist.

Ich habe mir übrigens gerade mal die Spring Unterstützung von myEclipse angeschaut. Das sieht doch sehr nett aus.
 
karatekid0815 hat gesagt.:
Ich habe mir übrigens gerade mal die Spring Unterstützung von myEclipse angeschaut. Das sieht doch sehr nett aus.
Zum Vergrößern anklicken....

Hehe, die integrieren die ganz normale Spring IDE mit jedem Release in ihr Bundle. Dementsprechend haben die etwas längere Releasezyklen. Du solltest also diese und ein paar mehr Features bekommen, wenn du die einfach einzeln in einen normale Eclipsedistri installierst...
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück