3:11 a.m.
[
https://jira.jboss.org/browse/WELD-737?page=com.atlassian.jira.plugin.sys...
]
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-int...
[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