Re: @SpringBean vs getApplication().getDao()
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: @SpringBean vs getApplication().getDao()
Sergey Podatelev mailto:brightnesslev...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: @SpringBean vs getApplication().getDao()
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 brightnesslev...@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 patr...@inertiabev.comwrote: 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- sp - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: @SpringBean vs getApplication().getDao()
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
brightnesslev...@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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: @SpringBean vs getApplication().getDao()
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 brightnesslev...@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()
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
valuetrue/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
james.austin.pe...@gmail.comwrote:
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
brightnesslev...@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
Re: @SpringBean vs getApplication().getDao()
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: @SpringBean vs getApplication().getDao()
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 patr...@inertiabev.comwrote: 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- sp
