Sasha, If you have time to make a minimal http://wicket.apache.org/quickstart.html quickstart project that demonstrates the issue you might find that you can save yourself "100 LOC", or at least that someone here will spot what's not right and then you can make your decision.
Regards - Cemal http://www.jWeekend.co.uk http://jWeekend.co.uk Sasha Ovsankin wrote: > > Cemal -- > >>> 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? > > By using little extra indirection we can solve this, too -- see my other > email to the list. > >>> 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...). > > We will see, but so far I have a solution that is under 100 LOC, works > for me and saves me from debugging in the internals of CGLib. > > I will still report the parent problem when I have time to compose a > test case. > > Thanks for your feedback, > -- Sasha > > jWeekend wrote: >> 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 beneat h 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] >>> >>> >>> >> > > > --------------------------------------------------------------------- > 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--tp19244802p19247600.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]
