Nach Aufbau des ApplicationContext weitere Bean-Definitionen dazuladen?

[DarthShader]

Jetzt habe ich mir nochmal die Spring 2.5 API angesehen und bemerkt, dass es folgenden Konstruktor gibt:


http://static.springsource.org/spri...stemXmlApplicationContext(java.lang.String[])

Als Parameter erwartet der ein Array aus Dateinamen, welche die Context-XML-Dateien sind. Ist das nicht schon die Lösung? Ich prüfe während des Bootstrappings einfach meine Konfigurationsdatei nach evtl. Modul-Einträgen. Abhängig davon erstelle ich dann das Dateinamen-Array für den FileSystemXmlApplicationContext-Konstruktor.

 

[kabel2]

Klar geht auch, warum nicht.
Dann muß die Entscheidung, ob bestimmte Beans dabei sein sollen oder nicht, aber außerhalb getroffen werden,
oder du verwirfst den Kontext dann wieder und baust einen neuen, der dann die richtigen XMLs reinzieht.

Nicht nur Perl kennt mehr als einen Weg, etwas zu tun.

Ich denke aber auch dass bei den geposteten Codebeispielen die Spring-Kenner gerade kopfschüttelnd wegsehen.
Ich kann mir gut vorstellen dass das nicht gerade die Art ist, in der Spring verwendet werden sollte.
Oder warum kann das Szenario sonst nicht einfacher ausgedrückt werden?

Ich will nochmal auf Ollies letztes Post zu sprechen kommen (falls Du noch mitliest...)

Kann man. Was machst du allerdings in einer Webapplikation? Da hast du nur wenig Einfluss auf die ApplicationContext-Implementierung bzw. -Auswahl. Testbarkeit ist auch so eine Sache. Eine Klasse kannst du testen. Einem Client aber vorzugeben nicht nur in welcher Reihenfolge Konfigurationsdateien geladen werden sollen, sondern auch noch, welche Datei in welchen AppContext geladen werden muss, der dann parent von welchem ist? Das klingt nicht danach, als wäre das sehr robust.

Also bei einer Webapplikation wird der ApplicationContext vom Servlet-Container vorgegeben?
Dir gehts hier also eher um die Allgemeinheit des Ansatzes, um einem ApplicationContext nachträglich zu verändern - macht Sinn.

Den Hinweis zur Testbarkeit hingegen verstehe ich nicht. Der Client sieht von dem ganzen Mist ja nichts - er bekommt eine Instanz von ApplicationContext in die Hand gedrückt, und gut ist. Wenn der Client jetzt das Casten anfängt (wie im Beispiel von mir weiter unten) dann ist auch der Client selbst schuld, wenn das irgendwann schief geht. Der einzige, der was zu testen hätte, ist DarthShader, der einfach gucken muß, ob bei bestimmten Konfigurationen bestimmte Beans vorhanden sind oder nicht. Vermutlich habe ich da noch was nicht verstanden... *sigh*

NB SCNR Wann werden eigentlich neben Vertex-, Pixel-, Geometry-, Hull-, und Domainshadern die DarthShader ausgeführt?
*duck und wech*

 

[DarthShader]

Klar, das ganze hat natürlich irgendwie einen komischen Beigeschmack, das Framework nicht so zu nutzen, wie es vielleicht eigentlich gedacht war. Aber der Ansatz ist nicht komplex und verbirgt nicht viel Arbeit, daher denke ich, ist es in gewissen Situationen zu tolerieren.

Den einen Ansatz aus dem Blog-Eintrag (Link weiter oben) fand ich auch interessant, nämlich via XML Tags Bedingungen in die Context-XML-Dateien einfügen zu können. Dies empfand ich recht intuitiv, also bestimmte Bean Definitionen quasi in einen "if-then" Block zu fassen. Das werde ich mir auch nochmal genauer ansehen, so könnte man ebenfalls sicher ein gutes Modul-System bauen.