tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship (JIRA)" <...@tapestry.apache.org>
Subject [jira] Assigned: (TAPESTRY-1631) tapestry-spring initializes lazy-init beans too soon
Date Mon, 03 Sep 2007 17:56:58 GMT

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

Howard M. Lewis Ship reassigned TAPESTRY-1631:

    Assignee: Howard M. Lewis Ship

> 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
>         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

View raw message