tapestry-spring initializes lazy-init beans too soon
----------------------------------------------------
Key: TAPESTRY-1631
URL: https://issues.apache.org/jira/browse/TAPESTRY-1631
Project: Tapestry
Issue Type: Bug
Components: tapestry-spring
Affects Versions: 5.0.5
Environment: Spring 2.0.4
Reporter: Nick James
We have some spring beans which are intended for various environments, so we
can have a weblogic transaction manager configured in a weblogic container, but
not when we run inside the Jetty container. To achieve this, we mark these
beans with the lazy-init=true attribute.
Starting in tapestry-spring 5.0.5, *all* of our spring beans get initialized at
startup, including the weblogic transaction manager., which results in a
ClassNotFoundException.
In SpringModuleDef.java, there is a method in the ModuleDef which looks like:
public Class getServiceInterface()
{
return getBean().getClass();
}
The call to getBean() causes the bean to be instantiated, and hence triggers
the CNFE. I have taken the liberty of patching this code, so that this method
makes a call to _context.getType(beanName) through an additional method
getBeanType() that I added.
This change passes the testing in maven, and after it is installed in my local
Maven repository, my application runs!
My only concern is that my code change is sending to Tapestry the type that
Spring thinks the bean is, rather than the actual Class of the bean. I expect
that means that proxies will look to Tapestry like the proxied type, instead of
the actual class of the proxy.
I have a very simple subversion patch that I will try to attach to this report.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
