I've read http://cwiki.apache.org/WICKET/spring.html and the corresponding section in "Wicket in Action" about the troubles with serialization of injected services.
"Dependencies often have references to other dependencies in the container, and so if one is serialized it will probably serialize a few others and can possibly cascade to serializing the entire container." (http://cwiki.apache.org/WICKET/spring.html) As far as I understand this is not a dependency injection specific issue. In either case all referenced objects are serialized recursively. So I think I have to take care about serialization not only when using Spring or Guice. Wouldn't it be sufficient to use a static member to hold a reference to a service? i.e. public class SomeWicketComponent{ private static MyService service; // ... } Remains the problem with the injection. To solve this the mentioned website suggests several ways. The Application Object Approach seems to be most wicket like to me. But as mentioned there it is very verbose. Why not simply insert a method to deliver requested beans into the Application class? It would look like this: class MyApplication extends WebApplication { private ApplicationContext ctx = new ClassPathXmlContext("context.xml"); // Spring context public Object getBean(String beanName){ return ctx.getBean(beanName); } } Is anything wrong with it? I find it much more elegant than to store a reference for each bean in in the application class as suggested on http://cwiki.apache.org/WICKET/spring.html#Spring-ApplicationObjectApproach. Maybe the annotation-based approach is a bit more elegant but I don't like annotations much. It seems to me, that dependency injection (DI) and wicket is not a dream team. Do you use DI with Wicket or do you use the "classic" approach like Wicket itself does? Thanks. Christian -- www.groovy-forum.de --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
