Re: @SpringBean injection -- why pretend?
Sasha,
Does the trace at the end of this note, in my PS, look familiar?
Now try the following code (notice the addition and use of the IBean2
interface) - things should work once you make the type of the reference in
your component (a Page in this case) the interface. If you can't do that on
your project (eg Bean2 is from a 3rd party library) then we'll have to take
another look.
Does that help?
===
public class SpringBeanPage extends WebPage{
@SpringBean IBean2 bean2;
public SpringBeanPage() {
add(new Label("sprung",bean2.getBean1().name));
}
}
public class Bean1 {
public String name;
@Override
public String toString() {
return name;
}
}
===
public class Bean2 implements IBean2 {
public Bean1 bean1;
protected Bean2(Bean1 bean1) {
super();
this.bean1 = bean1;
bean1.name = "Sprung";
}
public Bean1 getBean1() {
return bean1;
}
public void setBean1(Bean1 bean1) {
this.bean1 = bean1;
}
}
Regards - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk
PS Is this similar to the exception you saw?
org.apache.wicket.WicketRuntimeException: Can't instantiate page using
constructor public scratch.springbean.SpringBeanPage()
at
org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:168)
at
org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:58)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:262)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:283)
at
org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:210)
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:91)
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1166)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1243)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1331)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:493)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:363)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter.doFilterInternal(OpenEntityManagerInViewFilter.java:112)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:324)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:828)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown
Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at
org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:149)
... 29 more
Caused by: java.lang.RuntimeException: error while injecting object [[Page
class = scratch.springbean.SpringBeanPage, id = 0, version = 0]] of type
[scratch.springbean.SpringBeanPage]
at org.apache.wicket.injection.Injector.inject(Injector.java:118)
at
org.apache.wicket.injection.ConfigurableInjector.inject(ConfigurableInjector.java:39)
at
org.apache.wicket.injection.ComponentInjector.onInstantiation(ComponentInjector.java:52)
at
org.a
Re: @SpringBean injection -- why pretend?
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 map= new HashMap();
>>>
>>>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 {
> Applica
Re: @SpringBean injection -- why pretend?
Igor --
Here is what I had:
class Bean1 {...}
class Bean2 {
public Bean2(Bean1 bean1) {}
}
Spring config:
class MyPanel extends Panel {
...
@SpringBean Bean2 bean2;
...
}
The problem was that bean2 could not initialize, it was looking for
empty constructor which the class didn't have and failed. I tried using
property initialization but ended up with null value for Bean1 and
methods of bean2 were failing with NPE.
I had another group of beans like that in the program which was working
fine.
Another thing that got me scared was that the initializer for Bean1 got
called twice: once on application initialization and once on
initialization of the page. I spent some time within initialization
code, CGLib and such and figured I needed much more time to figure out
what's happening there.
I will report more on this problem when I have time to assemble test
case. I have workaround now and I am on to the next problem -- see my
separate email.
Thanks,
-- Sasha
Igor Vaynberg wrote:
On Sun, Aug 31, 2008 at 3:44 PM, Sasha Ovsankin
<[EMAIL PROTECTED]> wrote:
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.
how does springbean require you to debug cglib internals?
Locatable dao= new Locatable("myDAO", MyDAO.class);
Locatable dao= new Locatable("myDAO2", MyDAO2.class);
vs
@SpringBean MyDAO dao;
@SpringBean MyDAO2 dao2;
i still like springbean :) also, considering most of the frameworks
use cglib anyways (spring, hibernate, etc) you dont really win
anything...
-igor
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 map= new HashMap();
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
Re: @SpringBean injection -- why pretend?
On Sun, Aug 31, 2008 at 7:00 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > i still like springbean :) also, considering most of the frameworks > use cglib anyways (spring, hibernate, etc) you dont really win > anything... +1. @SpringBean has been no trouble for me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: @SpringBean injection -- why pretend?
On Sun, Aug 31, 2008 at 3:44 PM, Sasha Ovsankin
<[EMAIL PROTECTED]> wrote:
>
>>> 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.
how does springbean require you to debug cglib internals?
Locatable dao= new Locatable("myDAO", MyDAO.class);
Locatable dao= new Locatable("myDAO2", MyDAO2.class);
vs
@SpringBean MyDAO dao;
@SpringBean MyDAO2 dao2;
i still like springbean :) also, considering most of the frameworks
use cglib anyways (spring, hibernate, etc) you dont really win
anything...
-igor
>
> 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 map= new HashMap();
>>>
>>> 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());
>>
Re: @SpringBean injection -- why pretend?
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 map= new HashMap();
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 find(String name, C
Re: @SpringBean injection -- why pretend?
> class constructor is not called after deserialization...
Oops, I didn't know that :-$
In this case, I will need to use extra indirection; still pretty
straightforward:
class MyPage ... {
...
Locatable dao= new Locatable("myDAO", MyDAO.class);
...
dao.get().findSomething()
};
I have JUnit test that successfully tests the
serialization/deserialization of this thing. Can share the code if there
is interest.
Thanks for the feedback and for the great framework.
Igor Vaynberg wrote:
class constructor is not called after deserialization...
-igor
On Sun, Aug 31, 2008 at 12:31 PM, Sasha Ovsankin
<[EMAIL PROTECTED]> wrote:
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 yo ur 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 find(String name, Class 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: [
Re: @SpringBean injection -- why pretend?
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 map= new HashMap();
>
> 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 find(String name, Class 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
Re: @SpringBean injection -- why pretend?
class constructor is not called after deserialization...
-igor
On Sun, Aug 31, 2008 at 12:31 PM, Sasha Ovsankin
<[EMAIL PROTECTED]> wrote:
>> 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 find(String name, Class 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]
>
>
>>>
>>> --
Re: @SpringBean injection -- why pretend?
> 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 find(String name, Class 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]
Re: @SpringBean injection -- why pretend?
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 find(String name, Class 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]
Re: @SpringBean injection -- why pretend?
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 find(String name, Class 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]
Re: @SpringBean injection -- why pretend?
> 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 map= new HashMap();
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 find(String name, Class 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]
Re: @SpringBean injection -- why pretend?
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 find(String name, Class 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]
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: @SpringBean injection -- why pretend?
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 find(String name, Class 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]
>
>
>
--
View this message in context:
http://www.nabble.com/%40SpringBean-injectionwhy-pretend--tp19244802p19244850.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]
@SpringBean injection -- why pretend?
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 find(String name, Class 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]
@SpringBean injection -- why pretend?
Dear All -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
