If you mark that DAO as transient, what will happen after deserialising your page? Will you implement your own serialisation strategy to go with your home-made dependency injection mechanism? Are you just trying to avoid using Spring or do you just not like @SpringBean and the underlying Wicket proxying beneath the covers? FYI, it has worked fine for us.
You may end up with a solution that is quite convoluted, hard to learn/maintain, less elegant and hard to get just right in all cases (for example testing, serialization/deserialisation etc...). But at the end of the day, one of the key features of a framework like Wicket is that you can do anything that Java lets you - so the choice is always yours. Regards - Cemal http://www.jWeekend.co.uk http://jWeekend.co.uk Sasha Ovsankin wrote: > > > Are you planning on serialising your DAOs? > > No -- I mark them as "transient". > > > How will you mock out your "Locator" for unit tests? > > I didn't provide the implementation in the parent, but it's pretty > obvious: > > /** Use for unit tests */ > public static class MockLocator extends Locator { > HashMap<String, Object> map= new HashMap<String, Object>(); > > Object find(String name) { > return map.get(name); > } > > public void put(String name, Object value) { > map.put(name, value); > } > } > > class MyTest extends TestCase { > void setUp() { > MockLocator mockLocator= new MockLocator(); > MyDAO dao= new MyDAO(...); > mockLocator.put("dao", dao); > Locator.register(mockLocator); > } > } > > Hope this makes sense. > > jWeekend wrote: >> Are you planning on serialising your DAOs? >> How will you mock out your "Locator" for unit tests? >> >> Regards - Cemal >> http://www.jWeekend.co.uk http://jWeekend.co.uk >> >> >> >> Sasha O-2 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] > > > -- View this message in context: http://www.nabble.com/%40SpringBean-injection----why-pretend--tp19244802p19245428.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
