[weld-issues] [JBoss JIRA] Commented: (WELD-737) Proxy instantiation fails with IllegalAccessError for Beans with package private constructor

[Sivakumar Thyagarajan (JIRA)]

    [ https://jira.jboss.org/browse/WELD-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558698#action_12558698 ] 

Sivakumar Thyagarajan commented on WELD-737:
--------------------------------------------

Thanks Stuart for your analysis. Actually the ProxyServicesImpl that is currently in GF3.1 trunk [1] always provides the TCC(which is the web application classloader for the WAR), and this would work since the proxied bean and the proxy are loaded by the same classloader. 

Yes, I agree in general that the Package loaded for the proxy class and the proxied bean would be different if they are loaded via different classloaders. However, this scenario is unfortunately necessary because of the way Weld related classloading is done in OSGi as explained below.

Weld generated proxies have a dependency on two javassist interfaces: javassist.util.proxy.ProxyObject and javassist.util.proxy.MethodHandler (see ProxyFactory.createProxyClass and addFields). GlassFish's classloader obtained via ProxyServices.getClassLoader() is being used to load the proxy class as per the new Proxy SPI. The weld osgi bundle would not export the javassist packages if WELD-727 is fixed. Without the weld osgi bundle exporting the javassist interfaces, GlassFish has a new ProxyServicesImpl (see attached) that provides a delegate classloader as the proxy classloader. This delegate classloader delegates to Weld Bundle's classloader in addition to the application's classloader to make these unexported classes available in the classloader provided through ProxyServices.getClassLoader(). I saw the reported issue with this new classloader setup. So, in the future unless we revisit the proxy classloading scheme for OSGi environments (one place to look at is formalize what GlassFish's classloader is doing inside Weld itself similar to arrangement in Guice [2]), we would face this package-private access issue. 

[1] https://fisheye4.atlassian.com/browse/glassfish-svn/trunk/v3/web/weld-integration/src/main/java/org/glassfish/weld/services/ProxyServicesImpl.java?r=39992#l79
[2] Guice's bridge classloader http://code.google.com/p/google-guice/wiki/ClassLoading

> Proxy instantiation fails with IllegalAccessError for Beans with package private constructor
> --------------------------------------------------------------------------------------------
>
>                 Key: WELD-737
>                 URL: https://jira.jboss.org/browse/WELD-737
>             Project: Weld
>          Issue Type: Bug
>          Components: Proxies
>    Affects Versions: 1.1.0.Beta1
>            Reporter: Sivakumar Thyagarajan
>         Attachments: package-private-constructor-issue.tar.bz2
>
>
> For Beans with package private constructors, proxy instantiation fails with an Illegal access error as shown below. Since 1.1.0.Beta1 the proxy creation logic in ProxyFactory.addConstructors handles private constructors correctly but doesn't consider package private constructors.
> ----
> Caused by: java.lang.IllegalAccessError: tried to access method org.glassfish.tests.proxies.TestSessionScopedBean.<init>()V from class org.glassfish.tests.proxies.org$jboss$weld$bean-$export$work$workspaces$gfv3$v3$distributions$glassfish$target$glassfish3$glassfish$domains$domain1$applications$jsr88-1370237334428885039$-ManagedBean-class_org$glassfish$tests$proxies$TestSessionScopedBean_$$_WeldProxy
>         at org.glassfish.tests.proxies.org$jboss$weld$bean-$export$work$workspaces$gfv3$v3$distributions$glassfish$target$glassfish3$glassfish$domains$domain1$applications$jsr88-1370237334428885039$-ManagedBean-class_org$glassfish$tests$proxies$TestSessionScopedBean_$$_WeldProxy.<init>(org$jboss$weld$bean-$export$work$workspaces$gfv3$v3$distributions$glassfish$target$glassfish3$glassfish$domains$domain1$applications$jsr88-1370237334428885039$-ManagedBean-class_org$glassfish$tests$proxies$TestSessionScopedBean_$$_WeldProxy.java)
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>         at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>         at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>         at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
>         at java.lang.Class.newInstance0(Class.java:355)
>         at java.lang.Class.newInstance(Class.java:308)
>         at org.jboss.weld.util.reflection.SecureReflections$16.work(SecureReflections.java:396)
>         at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
>         at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInstantiation(SecureReflectionAccess.java:216)
>         at org.jboss.weld.util.reflection.SecureReflections.newInstance(SecureReflections.java:391)
>         at org.jboss.weld.bean.proxy.ProxyFactory.create(ProxyFactory.java:218)
>         at org.jboss.weld.bean.proxy.ClientProxyProvider.createClientProxy(ClientProxyProvider.java:89)
>         at org.jboss.weld.bean.proxy.ClientProxyProvider.access$000(ClientProxyProvider.java:40)
>         at org.jboss.weld.bean.proxy.ClientProxyProvider$1.apply(ClientProxyProvider.java:53)
>         at org.jboss.weld.bean.proxy.ClientProxyProvider$1.apply(ClientProxyProvider.java:44)
>         at com.google.common.collect.ComputingConcurrentHashMap.compute(ComputingConcurrentHashMap.java:206)
> ----

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira