You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Bryan Varner <bv...@polarislabs.com> on 2013/07/30 18:10:58 UTC
CGLib proxy issue with multi-module JEE .ears and @LocalBean (no
interface view) beans.
Hi all,
I believe I've found the root cause of the issue previously reported issue (long ago) which may not have ever turned into a 'bug':
http://apache-wicket.1842946.n4.nabble.com/java-lang-NoClassDefFoundError-with-wicket-proxy-ILazyInitProxy-in-Weblogic-9-2-td1921937.html
I too, am experiencing the same issue, on JBoss AS 7.2 (pre wildfly build).
We have an .ear containing an ejb-jar (with @LocalBean annotated no-interface ejbs) which we're trying to inject into our Wicket application, packaged in a separate .war file in the same .ear.
In the jboss container we have subdeployment isolation turned off.
When stepping through the code with a debugger, I get to the point where wicket is trying to create a CGLib proxy class to the non-final EJB class, and then things head south.
Here's a quick link to the code in question.
https://fisheye6.atlassian.com/browse/~raw,r=8d774aead8626981c56fa957a0169f115ba9eb36/wicket-git/wicket-ioc/src/main/java/org/apache/wicket/proxy/LazyInitProxyFactory.java
On line 175, the Enhancer is initially created and inherits the thread's contextClassLoader, which is the class loader for the .war module of our deployment package. This is fine, this classLoader has access to the ILazyInitProxy.class, the IWriteReplace.class, and (obviously) Serializable.
On line 178, when the superclass is set on the Enhancer, the Enhancer's classLoader changes to that of type.getClassLoader(). In our case, this the module class loader for the type.class -- or, our ejb-jar class loader, which does -not- have access to the the wicket .jars containing ILazyInitProxy.
When we get to line 190, things fail, with the underlying exception being ClassNotFound for ILazyInitProxy
This is kind of a problem. Sure, we could extract local interfaces for our EJBs, but it seems like the real problem here is that Wicket doesn't realize it may be in a multi-module deployment.
At this point, I'm leaning toward building a custom JavaEEComponentInjector which uses a custom AnnotJavaEEInjector, which uses a custom JavaEEProxyFieldValueFactory just so that I can redirect the invocations of LazyInitProxyFactory.createProxy() to a different method to experiment with this without having to rebuild all of wicket.
Thoughts?
Regards,
-Bryan Varner
Re: CGLib proxy issue with multi-module JEE .ears and @LocalBean (no
interface view) beans.
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
Please file a ticket so this is improved.
Thanks!
On Tue, Jul 30, 2013 at 6:47 PM, Bryan Varner <bv...@polarislabs.com>wrote:
> So it turns out that the original class loader (The one in use by the
> Enhancer when it's first constructed) has access to both classes (type, and
> org.apache.wicket.proxy.ILaxyInitProxy).
>
> My issue was solved by adding a
> e.setClassLoader(Thread.currentThread().getContextClassLoader()); after
> line 178.
>
> Regards,
> -Bryan Varner
>
> ________________________________________
> From: Bryan Varner [bvarner@polarislabs.com]
> Sent: Tuesday, July 30, 2013 12:10 PM
> To: dev@wicket.apache.org
> Subject: CGLib proxy issue with multi-module JEE .ears and @LocalBean (no
> interface view) beans.
>
> Hi all,
>
> I believe I've found the root cause of the issue previously reported issue
> (long ago) which may not have ever turned into a 'bug':
>
>
> http://apache-wicket.1842946.n4.nabble.com/java-lang-NoClassDefFoundError-with-wicket-proxy-ILazyInitProxy-in-Weblogic-9-2-td1921937.html
>
> I too, am experiencing the same issue, on JBoss AS 7.2 (pre wildfly build).
>
> We have an .ear containing an ejb-jar (with @LocalBean annotated
> no-interface ejbs) which we're trying to inject into our Wicket
> application, packaged in a separate .war file in the same .ear.
>
> In the jboss container we have subdeployment isolation turned off.
>
> When stepping through the code with a debugger, I get to the point where
> wicket is trying to create a CGLib proxy class to the non-final EJB class,
> and then things head south.
>
> Here's a quick link to the code in question.
>
> https://fisheye6.atlassian.com/browse/~raw,r=8d774aead8626981c56fa957a0169f115ba9eb36/wicket-git/wicket-ioc/src/main/java/org/apache/wicket/proxy/LazyInitProxyFactory.java
>
> On line 175, the Enhancer is initially created and inherits the thread's
> contextClassLoader, which is the class loader for the .war module of our
> deployment package. This is fine, this classLoader has access to the
> ILazyInitProxy.class, the IWriteReplace.class, and (obviously) Serializable.
> On line 178, when the superclass is set on the Enhancer, the Enhancer's
> classLoader changes to that of type.getClassLoader(). In our case, this the
> module class loader for the type.class -- or, our ejb-jar class loader,
> which does -not- have access to the the wicket .jars containing
> ILazyInitProxy.
>
> When we get to line 190, things fail, with the underlying exception being
> ClassNotFound for ILazyInitProxy
>
> This is kind of a problem. Sure, we could extract local interfaces for our
> EJBs, but it seems like the real problem here is that Wicket doesn't
> realize it may be in a multi-module deployment.
>
> At this point, I'm leaning toward building a custom
> JavaEEComponentInjector which uses a custom AnnotJavaEEInjector, which uses
> a custom JavaEEProxyFieldValueFactory just so that I can redirect the
> invocations of LazyInitProxyFactory.createProxy() to a different method to
> experiment with this without having to rebuild all of wicket.
>
> Thoughts?
>
> Regards,
> -Bryan Varner
>
RE: CGLib proxy issue with multi-module JEE .ears and @LocalBean
(no interface view) beans.
Posted by Bryan Varner <bv...@polarislabs.com>.
So it turns out that the original class loader (The one in use by the Enhancer when it's first constructed) has access to both classes (type, and org.apache.wicket.proxy.ILaxyInitProxy).
My issue was solved by adding a e.setClassLoader(Thread.currentThread().getContextClassLoader()); after line 178.
Regards,
-Bryan Varner
________________________________________
From: Bryan Varner [bvarner@polarislabs.com]
Sent: Tuesday, July 30, 2013 12:10 PM
To: dev@wicket.apache.org
Subject: CGLib proxy issue with multi-module JEE .ears and @LocalBean (no interface view) beans.
Hi all,
I believe I've found the root cause of the issue previously reported issue (long ago) which may not have ever turned into a 'bug':
http://apache-wicket.1842946.n4.nabble.com/java-lang-NoClassDefFoundError-with-wicket-proxy-ILazyInitProxy-in-Weblogic-9-2-td1921937.html
I too, am experiencing the same issue, on JBoss AS 7.2 (pre wildfly build).
We have an .ear containing an ejb-jar (with @LocalBean annotated no-interface ejbs) which we're trying to inject into our Wicket application, packaged in a separate .war file in the same .ear.
In the jboss container we have subdeployment isolation turned off.
When stepping through the code with a debugger, I get to the point where wicket is trying to create a CGLib proxy class to the non-final EJB class, and then things head south.
Here's a quick link to the code in question.
https://fisheye6.atlassian.com/browse/~raw,r=8d774aead8626981c56fa957a0169f115ba9eb36/wicket-git/wicket-ioc/src/main/java/org/apache/wicket/proxy/LazyInitProxyFactory.java
On line 175, the Enhancer is initially created and inherits the thread's contextClassLoader, which is the class loader for the .war module of our deployment package. This is fine, this classLoader has access to the ILazyInitProxy.class, the IWriteReplace.class, and (obviously) Serializable.
On line 178, when the superclass is set on the Enhancer, the Enhancer's classLoader changes to that of type.getClassLoader(). In our case, this the module class loader for the type.class -- or, our ejb-jar class loader, which does -not- have access to the the wicket .jars containing ILazyInitProxy.
When we get to line 190, things fail, with the underlying exception being ClassNotFound for ILazyInitProxy
This is kind of a problem. Sure, we could extract local interfaces for our EJBs, but it seems like the real problem here is that Wicket doesn't realize it may be in a multi-module deployment.
At this point, I'm leaning toward building a custom JavaEEComponentInjector which uses a custom AnnotJavaEEInjector, which uses a custom JavaEEProxyFieldValueFactory just so that I can redirect the invocations of LazyInitProxyFactory.createProxy() to a different method to experiment with this without having to rebuild all of wicket.
Thoughts?
Regards,
-Bryan Varner