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
<[email protected]>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 <
> [email protected]> 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
