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]
