[
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 formaliz!
e 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
_______________________________________________
weld-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-issues
