You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Sergey Podatelev <br...@gmail.com> on 2009/02/17 17:55:34 UTC
@SpringBean vs getApplication().getDao()
Okay, this question might actually be more related to Spring, but I'm
completely lost here, and my question on Spring forums usually don't get any
replies, so I hope Wicket community might help as it usually does.
I'm using JCR, and have a RepositoryDao bean configured in
applicationContext.xml.
RepositoryDao has a "template" property which points to an instance of
JcrTemplate in applicationContext.xml, all repository access is performed
through that template.
I have an AccessPage which has a RepositoryDao injected via @SpringBean.
There is an inner class Form on that page, it has a default submit button
and three submit buttons that skip default processing and perform their own
operations onSubmit(). Both default button and skip-default-processing
buttons use the same repositoryDao property of AccessPage to perform certain
operations on repository.
I noticed that when I actually open that AccessPage, there's a new
RepositoryDao object created, and it's "template" property is null. When I
press any of those non-default submit buttons of the form, everything works
fine. But on default button onSubmit(), I see that there's yet another
insance of RepositoryDao created, and it's "template" is also null, which
leads to NullPointerException.
I assumed that beans configured in applicationContext.xml are actually
singletons, so there won't be any new instances of such nodes upon
pages-with-injections instantiation.
Regardless of whether that assumption is correct/incorrect/my-god-rtfm, I
still won't understand why default submit button reaction is NPE as it uses
same partnershipDao property of AccessPage.
Could someone please elaborate some internal differences of the
annotation-based approach as opposed to storing DAOs in Application object.
In the latter case it's quite clear that there's a single instance of
RepositoryDao as a property of MyApplication which is pulled on
((MyApplication) Application.get()).getRepositoryDao().
Thanks.
--
sp
Re: @SpringBean vs getApplication().getDao()
Posted by James Carman <jc...@carmanconsulting.com>.
Well, in order for the reference to be set, the object used must
adhere to the same API. The object is, indeed a proxy. So, the proxy
either implements the same interface as the type of the field or
extends the class of the type of the field (you should be using
interfaces if at all possible).
On Wed, Feb 18, 2009 at 1:59 AM, Sergey Podatelev
<br...@gmail.com> wrote:
> Thanks for your insight, Patrick.
>
> But I'm stuck in my dumbness: "setting the component's fields" -- does this
> mean a new instance of that particular annotated bean is created, or that
> singleton is accessed somehow (proxy)?
> Also, it's not the injected beans that are null, it's their dependencies,
> and I assume that is because new instances of those beans are created.
>
>
> On Wed, Feb 18, 2009 at 9:13 AM, Patrick Angeles <pa...@inertiabev.com>wrote:
>
>>
>>
>> To answer your question, yes spring beans are singleton by default. The
>> @SpringBean annotation works roughly like this: in your Application class,
>> you set a ComponentInstantiationListener which gets called every time a
>> Wicket page/component is instantiated. The particular listener that gets
>> set
>> (SpringComponentInjector) takes care of setting the component's fields that
>> are annotated with @SpringBean with the appropriate beans found in the
>> spring context.
>>
>> My guess is that the Listener isn't being configured properly, and that is
>> why your @SpringBeans are null...
>>
>>
>>
>> Sergey Podatelev wrote:
>> >
>> > Okay, this question might actually be more related to Spring, but I'm
>> > completely lost here, and my question on Spring forums usually don't get
>> > any
>> > replies, so I hope Wicket community might help as it usually does.
>> >
>> > I'm using JCR, and have a RepositoryDao bean configured in
>> > applicationContext.xml.
>> > RepositoryDao has a "template" property which points to an instance of
>> > JcrTemplate in applicationContext.xml, all repository access is performed
>> > through that template.
>> >
>> > I have an AccessPage which has a RepositoryDao injected via @SpringBean.
>> > There is an inner class Form on that page, it has a default submit button
>> > and three submit buttons that skip default processing and perform their
>> > own
>> > operations onSubmit(). Both default button and skip-default-processing
>> > buttons use the same repositoryDao property of AccessPage to perform
>> > certain
>> > operations on repository.
>> >
>> > I noticed that when I actually open that AccessPage, there's a new
>> > RepositoryDao object created, and it's "template" property is null. When
>> I
>> > press any of those non-default submit buttons of the form, everything
>> > works
>> > fine. But on default button onSubmit(), I see that there's yet another
>> > insance of RepositoryDao created, and it's "template" is also null, which
>> > leads to NullPointerException.
>> >
>> > I assumed that beans configured in applicationContext.xml are actually
>> > singletons, so there won't be any new instances of such nodes upon
>> > pages-with-injections instantiation.
>> >
>> > Regardless of whether that assumption is correct/incorrect/my-god-rtfm, I
>> > still won't understand why default submit button reaction is NPE as it
>> > uses
>> > same partnershipDao property of AccessPage.
>> >
>> > Could someone please elaborate some internal differences of the
>> > annotation-based approach as opposed to storing DAOs in Application
>> > object.
>> > In the latter case it's quite clear that there's a single instance of
>> > RepositoryDao as a property of MyApplication which is pulled on
>> > ((MyApplication) Application.get()).getRepositoryDao().
>> >
>> > Thanks.
>> >
>> > --
>> > sp
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/%40SpringBean-vs-getApplication%28%29.getDao%28%29-tp22061472p22072806.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> sp
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: @SpringBean vs getApplication().getDao()
Posted by Martijn Reuvers <ma...@gmail.com>.
Hey Sergey,
As far as I know it should create only a single instance for each
spring bean (if they are singletons that is). Thus always the same
bean should be injected into your wicket classes. Does this problem
occur with the @SpringBean or using the proxy approach? I've been
using @SpringBean and never encountered this particular issue before.
Perhaps theress something wrong with the proxy approach or its not
configured properly. Could you try using @SpringBean, see Patricks
reply on how to enable this.
Martijn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: @SpringBean vs getApplication().getDao()
Posted by Kai Mütz <km...@googlemail.com>.
Sergey Podatelev <ma...@gmail.com> wrote:
> Thanks for your insight, Patrick.
>
> But I'm stuck in my dumbness: "setting the component's fields" --
> does this mean a new instance of that particular annotated bean is
> created, or that singleton is accessed somehow (proxy)?
> Also, it's not the injected beans that are null, it's their
> dependencies,
> and I assume that is because new instances of those beans are created.
>
Do you have tested the repositoryDao with
AbstractDependencyInjectionSpringContextTests? Does this problem only occurs
if you access the repositoryDao from a Wicket component?
See
http://static.springframework.org/spring/docs/2.5.x/reference/testing.html#j
unit38-legacy-support
Cheers, Kai
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: @SpringBean vs getApplication().getDao()
Posted by Sergey Podatelev <br...@gmail.com>.
Thanks for your insight, Patrick.
But I'm stuck in my dumbness: "setting the component's fields" -- does this
mean a new instance of that particular annotated bean is created, or that
singleton is accessed somehow (proxy)?
Also, it's not the injected beans that are null, it's their dependencies,
and I assume that is because new instances of those beans are created.
On Wed, Feb 18, 2009 at 9:13 AM, Patrick Angeles <pa...@inertiabev.com>wrote:
>
>
> To answer your question, yes spring beans are singleton by default. The
> @SpringBean annotation works roughly like this: in your Application class,
> you set a ComponentInstantiationListener which gets called every time a
> Wicket page/component is instantiated. The particular listener that gets
> set
> (SpringComponentInjector) takes care of setting the component's fields that
> are annotated with @SpringBean with the appropriate beans found in the
> spring context.
>
> My guess is that the Listener isn't being configured properly, and that is
> why your @SpringBeans are null...
>
>
>
> Sergey Podatelev wrote:
> >
> > Okay, this question might actually be more related to Spring, but I'm
> > completely lost here, and my question on Spring forums usually don't get
> > any
> > replies, so I hope Wicket community might help as it usually does.
> >
> > I'm using JCR, and have a RepositoryDao bean configured in
> > applicationContext.xml.
> > RepositoryDao has a "template" property which points to an instance of
> > JcrTemplate in applicationContext.xml, all repository access is performed
> > through that template.
> >
> > I have an AccessPage which has a RepositoryDao injected via @SpringBean.
> > There is an inner class Form on that page, it has a default submit button
> > and three submit buttons that skip default processing and perform their
> > own
> > operations onSubmit(). Both default button and skip-default-processing
> > buttons use the same repositoryDao property of AccessPage to perform
> > certain
> > operations on repository.
> >
> > I noticed that when I actually open that AccessPage, there's a new
> > RepositoryDao object created, and it's "template" property is null. When
> I
> > press any of those non-default submit buttons of the form, everything
> > works
> > fine. But on default button onSubmit(), I see that there's yet another
> > insance of RepositoryDao created, and it's "template" is also null, which
> > leads to NullPointerException.
> >
> > I assumed that beans configured in applicationContext.xml are actually
> > singletons, so there won't be any new instances of such nodes upon
> > pages-with-injections instantiation.
> >
> > Regardless of whether that assumption is correct/incorrect/my-god-rtfm, I
> > still won't understand why default submit button reaction is NPE as it
> > uses
> > same partnershipDao property of AccessPage.
> >
> > Could someone please elaborate some internal differences of the
> > annotation-based approach as opposed to storing DAOs in Application
> > object.
> > In the latter case it's quite clear that there's a single instance of
> > RepositoryDao as a property of MyApplication which is pulled on
> > ((MyApplication) Application.get()).getRepositoryDao().
> >
> > Thanks.
> >
> > --
> > sp
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/%40SpringBean-vs-getApplication%28%29.getDao%28%29-tp22061472p22072806.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
sp
Re: @SpringBean vs getApplication().getDao()
Posted by Patrick Angeles <pa...@inertiabev.com>.
To answer your question, yes spring beans are singleton by default. The
@SpringBean annotation works roughly like this: in your Application class,
you set a ComponentInstantiationListener which gets called every time a
Wicket page/component is instantiated. The particular listener that gets set
(SpringComponentInjector) takes care of setting the component's fields that
are annotated with @SpringBean with the appropriate beans found in the
spring context.
My guess is that the Listener isn't being configured properly, and that is
why your @SpringBeans are null...
Sergey Podatelev wrote:
>
> Okay, this question might actually be more related to Spring, but I'm
> completely lost here, and my question on Spring forums usually don't get
> any
> replies, so I hope Wicket community might help as it usually does.
>
> I'm using JCR, and have a RepositoryDao bean configured in
> applicationContext.xml.
> RepositoryDao has a "template" property which points to an instance of
> JcrTemplate in applicationContext.xml, all repository access is performed
> through that template.
>
> I have an AccessPage which has a RepositoryDao injected via @SpringBean.
> There is an inner class Form on that page, it has a default submit button
> and three submit buttons that skip default processing and perform their
> own
> operations onSubmit(). Both default button and skip-default-processing
> buttons use the same repositoryDao property of AccessPage to perform
> certain
> operations on repository.
>
> I noticed that when I actually open that AccessPage, there's a new
> RepositoryDao object created, and it's "template" property is null. When I
> press any of those non-default submit buttons of the form, everything
> works
> fine. But on default button onSubmit(), I see that there's yet another
> insance of RepositoryDao created, and it's "template" is also null, which
> leads to NullPointerException.
>
> I assumed that beans configured in applicationContext.xml are actually
> singletons, so there won't be any new instances of such nodes upon
> pages-with-injections instantiation.
>
> Regardless of whether that assumption is correct/incorrect/my-god-rtfm, I
> still won't understand why default submit button reaction is NPE as it
> uses
> same partnershipDao property of AccessPage.
>
> Could someone please elaborate some internal differences of the
> annotation-based approach as opposed to storing DAOs in Application
> object.
> In the latter case it's quite clear that there's a single instance of
> RepositoryDao as a property of MyApplication which is pulled on
> ((MyApplication) Application.get()).getRepositoryDao().
>
> Thanks.
>
> --
> sp
>
>
--
View this message in context: http://www.nabble.com/%40SpringBean-vs-getApplication%28%29.getDao%28%29-tp22061472p22072806.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: @SpringBean vs getApplication().getDao()
Posted by Sergey Podatelev <br...@gmail.com>.
Okay, thanks for you replies, my question was poorly formulated. There are
two issues here.
First problem is that I apparently don't understand some very basic
principles behind Spring-configured beans handling.
I assume that a DAO configured in Spring are created on application
deployment, specifically, application context initialization. This DAO is
also configured in applicationContext.xml to have as a property whatever
data source it needs like a JcrTemplate in case of JCR DAO or something like
JndiObjectFactoryBean in case of database.
When I have MyApplication configured to have reference to MyDao bean in
applicationContext.xml, upon app context initialization that myDao property
of MyApp is set to a reference of an instance of MyDao class, which is a
singleton. Then, on my pages, I actually access that myDao property of MyApp
via ((MyApp) Application.get()).getMyDao() and in case I follow that
proxy-based approach described on Wicket+Spring wiki page, I get a reference
to that singleton through some sort of proxy.
When I use annotation-based approach, however, I can actually see that MyDao
is instantiated several times (well, at least MyDao() constructor is called
several times), specifically, once on MyApp initialization, once when page,
that has that DAO injected, is created and in certain cases, once when I
actually call some method of that DAO.
Now here's the second part of the problem:
I have a RepositoryDao:
class RepositoryDao {
private JcrTemplate template;
public void setTemplate(JcrTemplate template) {
this.template = template;
}
}
...configured in spring's appContext.xml (jcrSessionFactory and jcrTemplate
beans are ommited here):
<bean id="repositoryDaoTransactionManager"
class="org.springmodules.jcr.jackrabbit.LocalTransactionManager">
<property name="sessionFactory" ref="jcrSessionFactory"/>
</bean>
<bean id="repositoryDaoTxProxyTemplate" abstract="true"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="proxyTargetClass">
<value>true</value>
</property>
<property name="transactionManager"
ref="repositoryDaoTransactionManager"/>
<property name="transactionAttributes">
<props>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="*">PROPAGATION_REQUIRED, readOnly</prop>
</props>
</property>
</bean>
<bean id="repositoryDaoJcrService"
parent="repositoryDaoTxProxyTemplate">
<property name="target" ref="repositoryDao" />
</bean>
<bean id="repositoryDao"
class="com.myapp.RepositoryDao">
<property name="template" ref="jcrTemplate" />
</bean>
And an AccessPage:
class AccessPage {
@SpringBean(name="repositoryDao")
RepositoryDao repositoryDao;
public AccessPage() {
add(new MyForm());
}
class MyForm extends Form {
public MyForm() {
...
Button button2 = new Button("button2") {
@Override public void onSubmit() {
repositoryDao.doB();
}
}
button2.setDefaultFormProcessing(false);
add(button2);
Button button3 = new Button("button3") {
@Override public void onSubmit() {
repositoryDao.doC();
}
}
button3.setDefaultFormProcessing(false);
add(button3);
}
public void onSubmit() {
repositoryDao.doA();
}
}
}
doA(), doB() and doC() all start from calling template.execute().
The problem is, when I hit button2 or button3, everything works fine, doB()
and doC() do work.
Default form submit button, however, leads to NPE as template is null.
Again, I'm sorry if this is off the topic, but I'd really like to find out
how these things actually work, and digging through all the code seems to be
a bit hardcore in this case.
On Tue, Feb 17, 2009 at 8:42 PM, James Perry
<ja...@gmail.com>wrote:
> As far as I am aware, the main internal differential is that annotations
> provides a quick, safe way to access your spring beans and ensure that the
> whole container does not get serialized via a proxy. However the magic
> comes
> at a cost that it will serial the bean id (as a string) - which can be
> costly if used a lot in your components. On the other side of the coin,
> using the other option does not have any serialization cost but its very
> vulnerable to accidentally serializing the bean and, potentially, the whole
> application context.
>
> Personally I use the latter option where I access my service facade bean by
> a static import. I prefer this route as I am paranoid about memory usage
> but
> each their own.
>
> Best,
> James.
>
> On Tue, Feb 17, 2009 at 4:55 PM, Sergey Podatelev <
> brightnesslevels@gmail.com> wrote:
>
> > Okay, this question might actually be more related to Spring, but I'm
> > completely lost here, and my question on Spring forums usually don't get
> > any
> > replies, so I hope Wicket community might help as it usually does.
> >
> > I'm using JCR, and have a RepositoryDao bean configured in
> > applicationContext.xml.
> > RepositoryDao has a "template" property which points to an instance of
> > JcrTemplate in applicationContext.xml, all repository access is performed
> > through that template.
> >
> > I have an AccessPage which has a RepositoryDao injected via @SpringBean.
> > There is an inner class Form on that page, it has a default submit button
> > and three submit buttons that skip default processing and perform their
> own
> > operations onSubmit(). Both default button and skip-default-processing
> > buttons use the same repositoryDao property of AccessPage to perform
> > certain
> > operations on repository.
> >
> > I noticed that when I actually open that AccessPage, there's a new
> > RepositoryDao object created, and it's "template" property is null. When
> I
> > press any of those non-default submit buttons of the form, everything
> works
> > fine. But on default button onSubmit(), I see that there's yet another
> > insance of RepositoryDao created, and it's "template" is also null, which
> > leads to NullPointerException.
> >
> > I assumed that beans configured in applicationContext.xml are actually
> > singletons, so there won't be any new instances of such nodes upon
> > pages-with-injections instantiation.
> >
> > Regardless of whether that assumption is correct/incorrect/my-god-rtfm, I
> > still won't understand why default submit button reaction is NPE as it
> uses
> > same partnershipDao property of AccessPage.
> >
> > Could someone please elaborate some internal differences of the
> > annotation-based approach as opposed to storing DAOs in Application
> object.
> > In the latter case it's quite clear that there's a single instance of
> > RepositoryDao as a property of MyApplication which is pulled on
> > ((MyApplication) Application.get()).getRepositoryDao().
> >
> > Thanks.
> >
> > --
> > sp
> >
>
--
sp
Re: @SpringBean vs getApplication().getDao()
Posted by James Perry <ja...@gmail.com>.
As far as I am aware, the main internal differential is that annotations
provides a quick, safe way to access your spring beans and ensure that the
whole container does not get serialized via a proxy. However the magic comes
at a cost that it will serial the bean id (as a string) - which can be
costly if used a lot in your components. On the other side of the coin,
using the other option does not have any serialization cost but its very
vulnerable to accidentally serializing the bean and, potentially, the whole
application context.
Personally I use the latter option where I access my service facade bean by
a static import. I prefer this route as I am paranoid about memory usage but
each their own.
Best,
James.
On Tue, Feb 17, 2009 at 4:55 PM, Sergey Podatelev <
brightnesslevels@gmail.com> wrote:
> Okay, this question might actually be more related to Spring, but I'm
> completely lost here, and my question on Spring forums usually don't get
> any
> replies, so I hope Wicket community might help as it usually does.
>
> I'm using JCR, and have a RepositoryDao bean configured in
> applicationContext.xml.
> RepositoryDao has a "template" property which points to an instance of
> JcrTemplate in applicationContext.xml, all repository access is performed
> through that template.
>
> I have an AccessPage which has a RepositoryDao injected via @SpringBean.
> There is an inner class Form on that page, it has a default submit button
> and three submit buttons that skip default processing and perform their own
> operations onSubmit(). Both default button and skip-default-processing
> buttons use the same repositoryDao property of AccessPage to perform
> certain
> operations on repository.
>
> I noticed that when I actually open that AccessPage, there's a new
> RepositoryDao object created, and it's "template" property is null. When I
> press any of those non-default submit buttons of the form, everything works
> fine. But on default button onSubmit(), I see that there's yet another
> insance of RepositoryDao created, and it's "template" is also null, which
> leads to NullPointerException.
>
> I assumed that beans configured in applicationContext.xml are actually
> singletons, so there won't be any new instances of such nodes upon
> pages-with-injections instantiation.
>
> Regardless of whether that assumption is correct/incorrect/my-god-rtfm, I
> still won't understand why default submit button reaction is NPE as it uses
> same partnershipDao property of AccessPage.
>
> Could someone please elaborate some internal differences of the
> annotation-based approach as opposed to storing DAOs in Application object.
> In the latter case it's quite clear that there's a single instance of
> RepositoryDao as a property of MyApplication which is pulled on
> ((MyApplication) Application.get()).getRepositoryDao().
>
> Thanks.
>
> --
> sp
>
Re: @SpringBean vs getApplication().getDao()
Posted by Martijn Reuvers <ma...@gmail.com>.
Hello,
I am not entirely sure if I understand your question correctly. But I
usually use Spring like this:
YourDao (either defined in applicationContext.xml or in separate
spring-config files, or annotation-driven e.g. with @Repository. The
template you mention I usually autowire into the dao so basically it
looks like (this example is annotation-driven):
@Repository (value="myDao")
class YourDao {
@Autowired
private YourTemplate yourTemplate;
public void xxx() {
// use your template here
}
}
In Wicket you can then use :
@SpringBean (name="myDao")
private YourDao yourDao;
You can do the same using wiring through xml files, the idea is the
same nevertheless. If you need 'larger' services I'd advice to use a
service layer (which uses multiple dao's or whatever is needed to do
the work in a single transaction), the latter is just a matter of
taste.
Martijn
On Tue, Feb 17, 2009 at 5:55 PM, Sergey Podatelev
<br...@gmail.com> wrote:
> Okay, this question might actually be more related to Spring, but I'm
> completely lost here, and my question on Spring forums usually don't get any
> replies, so I hope Wicket community might help as it usually does.
>
> I'm using JCR, and have a RepositoryDao bean configured in
> applicationContext.xml.
> RepositoryDao has a "template" property which points to an instance of
> JcrTemplate in applicationContext.xml, all repository access is performed
> through that template.
>
> I have an AccessPage which has a RepositoryDao injected via @SpringBean.
> There is an inner class Form on that page, it has a default submit button
> and three submit buttons that skip default processing and perform their own
> operations onSubmit(). Both default button and skip-default-processing
> buttons use the same repositoryDao property of AccessPage to perform certain
> operations on repository.
>
> I noticed that when I actually open that AccessPage, there's a new
> RepositoryDao object created, and it's "template" property is null. When I
> press any of those non-default submit buttons of the form, everything works
> fine. But on default button onSubmit(), I see that there's yet another
> insance of RepositoryDao created, and it's "template" is also null, which
> leads to NullPointerException.
>
> I assumed that beans configured in applicationContext.xml are actually
> singletons, so there won't be any new instances of such nodes upon
> pages-with-injections instantiation.
>
> Regardless of whether that assumption is correct/incorrect/my-god-rtfm, I
> still won't understand why default submit button reaction is NPE as it uses
> same partnershipDao property of AccessPage.
>
> Could someone please elaborate some internal differences of the
> annotation-based approach as opposed to storing DAOs in Application object.
> In the latter case it's quite clear that there's a single instance of
> RepositoryDao as a property of MyApplication which is pulled on
> ((MyApplication) Application.get()).getRepositoryDao().
>
> Thanks.
>
> --
> sp
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org