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]

Reply via email to