Wicket mit Spring ohne extra Proxies

[deamon]

Hallo,

ich habe gerade in dem Buch "Wicket in Action" gelesen, dass man in Klassen der Wicket-Anwendung keine Referenzen auf Spring-Beans halten soll, weil Spring Proxy-Objekte erzeugt, die eine Referenz auf den ApplicationContext enthalten und somit beim persistieren jeder Seite der gesamte ApplicationContext mitgespeichert würde!

Als Lösung schlagen sie die Verwendung eines Wicket-Unterprojekts für die Spring-Integration vor. Diese Bibliothek erzeugt Proxies, die die SpringBeans kapseln. Besonders elegant finde ich diesen Ansatz aber nicht. Das Beispiel ohne Annotations finde ich sogar hässlich.

Nun meine Frage: würde es nicht auch reichen, wenn man in den Klassen der Wicket-Anwendung die von Spring injizierten Referenzen statisch machen würde? Es gibt schließlich keinen Grund warum jede Klasse eine eigene Referenz auf einen Dienst haben sollte. Problematisch wäre es nur, wenn es - warum auch immer - doch keine Singletons mehr sein sollen. Allerdings könnte man auch leicht das Wort "static" vergessen und würde sich im Betrieb über den Speicherbedarf und die Performance der Anwendung wundern ...

Wie ist das mit anderen DI-Frameworks wie z. B. Google Guice? Erzeugen die auch Proxies? Für DI an sich bräuchte man das vermutlich nicht. Soweit ich weiß ist das bei Spring wegen AOP der Fall.

Oder bleibt man bei Wicket besser bei "unmanaged code" und verzichtet ganz auf DI? Wie sind eure Erfahrungen?

 

[byte]

ich habe gerade in dem Buch "Wicket in Action" gelesen, dass man in Klassen der Wicket-Anwendung keine Referenzen auf Spring-Beans halten soll, weil Spring Proxy-Objekte erzeugt, die eine Referenz auf den ApplicationContext enthalten und somit beim persistieren jeder Seite der gesamte ApplicationContext mitgespeichert würde!

Kann mir nicht vorstellen, dass das da so steht, denn es ist schlichtweg falsch. Spring macht zwar massiv gebrauch von Proxies, aber wenn man eine einfache Bean erzeugt, dann ist das kein Proxy sondern ein einfaches Objekt. Proxies kommen erst ins Spiel, wenn man AOP einsetzt. Und auch da kann man wählen, ob man AOP mittels JDK-Proxies realisieren will oder per AspectJ (Load Time Weaving, also Bytecode Instrumentation).
Ebenso falsch ist, dass jede Spring Bean eine Referenz auf den ApplicationContext bekommt. Das ist absoluter Käse und nur in den seltensten Fällen so, z.b. wenn die Bean das Interface ApplicationContextAware implementiert.

 

[deamon]

In Wicket in Action steht auf Seite 309:
"One problem with code from the previous section ist that it can lead to memory leaks. Be careful never to hold a reference to a Spring bean in your components. Spring often creates proxies for the beans it creates (for instance, to support transactions), and when Wicket serializes your components - as it does for every request, if you use the default session store - you may end up serializing the entire Spring container with them."

Dann kommt ein als problematisch bezeichnetes Beispiel, in dem ein Service von Spring erzeugt wird und eine Referenz darauf in einer Instanzvariable einer Komponente gespeichert wird.

Ich wundere mich auch, dass der ganze Container serialisiert werden sollte, aber wenn es kein Problem wäre, hätten die Wicket-Entwickler sicher kein Unterprojekt für dessen Lösung ins Leben gerufen. Und da der Code nicht davon abhängen sollte, ob man AOP mit oder ohne Proxy macht, wäre es sicherer die Wicket-Proxies zu verwenden.

 

[byte]

Ich kenne Wicket nicht, daher kann ich dazu nichts sagen. Spricht aber auf jeden Fall nicht für das Framework, wenn es mit Proxies Probleme hat.

 

[deamon]

Ich denke, es handelt sich hier um kein Wicket-spezifisches Problem, sondern um ein Grundproblem der Serialisierung. Das Problem tritt bei Wicket nur deutlich zu Tage, weil einfach viel serialsiert wird.

Auf der Seite http://cwiki.apache.org/WICKET/spring.html ist das Problem genauer beschrieben.