[jira] Closed: (TAPESTRY-1631) tapestry-spring initializes lazy-init beans too soon

["Howard M. Lewis Ship (JIRA)" <de...@tapestry.apache.org>]

     [ https://issues.apache.org/jira/browse/TAPESTRY-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Howard M. Lewis Ship closed TAPESTRY-1631.
------------------------------------------

       Resolution: Fixed
    Fix Version/s: 5.0.6

Thanks for the patch.

> 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
>            Assignee: Howard M. Lewis Ship
>             Fix For: 5.0.6
>
>         Attachments: tapestry-spring-1631.patch
>
>
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org