what happens after your page is serialized and deserialized, then dao is null...
-igor On Sun, Aug 31, 2008 at 12:09 PM, Sasha Ovsankin <[EMAIL PROTECTED]> wrote: >>> The problem is keeping a reference to the service. > > Right, actually I skipped the "transient" keyword I use in my code: > > class MyPage { > ... > transient MyDAO dao= Locator.find("myDAO", MyDAO.class); > ... > } > > "transient" prevents the field from being serialized. > >>> You might be good >>> enough to understand that, but how good do you trust your co-workers, >>> and even new members joining your team? > > So, I will have to tell them to use the above pattern, just like telling > them to use @SpringBean? > > Regardless, it seems that every engineer working with Wicket have to hit > their "serialization bump" one day, as you hint in your book. We'll find out > :-) > > Thanks for the book by the way. It made me go much faster. > > Martijn Dashorst wrote: >> >> Did you read http://cwiki.apache.org/WICKET/spring.html and see why >> @SpringBean is important? >> >> The problem is keeping a reference to the service. You might be good >> enough to understand that, but how good do you trust your co-workers, >> and even new members joining your team? >> >> Martijn >> >> On Sun, Aug 31, 2008 at 8:23 PM, Sasha Ovsankin >> <[EMAIL PROTECTED]> wrote: >>> >>> Dear All -- >>> >>> I was having an issue with @SpringBean injection -- my dao class was not >>> initialized properly with the dependent beans. I spent some time >>> exploring >>> internals of CGLib and Spring Injections and then a thought struck me: >>> how >>> really helpful is this injection? >>> >>> Consider this code: >>> >>> class MyPage extends Page { >>> ... >>> @SpringBean >>> MyDAO dao; >>> ... >>> } >>> >>> vs. this code: >>> >>> class MyPage { >>> ... >>> MyDAO dao= Locator.find("myDAO", MyDAO.class); >>> ... >>> } >>> >>> The Locator is a pretty straightforward guy who pulls ApplicationContext >>> out of thin air^^^^^ThreadLocal variable and looks up on it, see the >>> example >>> code below. >>> >>> The former uses annotations, CGLIB and delicate injection. The latter >>> uses >>> nothing and is a lot simpler and robust. Aside from marginal savings in >>> typing I couldn't find any advantages of the former approach. Can you? >>> >>> Unless convinced otherwise, I am going to skip the @SpringBean altogether >>> and use the Locator thing in my application. >>> >>> Thanks, >>> -- Sasha >>> >>> ----------------------------------------------------------------------- >>> public abstract class Locator { >>> >>> abstract Object find(String name); >>> >>> static Locator locator= null; >>> >>> public static Locator register(Locator inLocator) { >>> Locator result= locator; >>> locator= inLocator; >>> return result; >>> } >>> >>> public static class SpringLocator extends Locator { >>> ApplicationContext context= >>> WebApplicationContextUtils.getRequiredWebApplicationContext( >>> WebApplication.get().getServletContext()); >>> Object find(String name) { >>> return context.getBean(name); >>> } >>> } >>> >>> /** To be called in the application initialization */ >>> public static void registerSpringLocator() { >>> register(new SpringLocator()); >>> } >>> >>> /** Use for unit tests */ >>> public static class MockLocator extends Locator { >>> @Override >>> Object find(String name) { >>> // TODO implement >>> return null; >>> } >>> } >>> >>> public static<T> T find(String name, Class<T> clazz) { >>> Object found= locator.find(name); >>> if (found==null) >>> return null; >>> return clazz.cast(found); >>> } >>> } >>> ----------------------------------------------------------------------- >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]