> what happens after your page is serialized and deserialized, then dao
> is null...
The dao field is supposed to be initialized again in the class constructor.
Igor Vaynberg wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
