[TAPESTRY-1631] tapestry-spring initializes lazy-init beans too soon

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 5.0.5
• Fix Version/s: 5.0.6
• Component/s: tapestry-spring
• Environment: Spring 2.0.4
• Assignee: Howard Lewis Ship
• Reporter: Nick James
• Created: 06/Jul/07 21:49
• Updated: 03/Sep/07 18:00
• Resolved: 03/Sep/07 18:00

Description

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.