It would be really really great to have more eyes on the tck.

This particular problem seems to be due to an interaction between geronimo and 
openejb.  In geronimo the classloader that the proxy is attached to is a 
wrapper for the osgi bundle and doesn't actually load any classes itself.  So 
once the proxy is attached to that classloader it becomes completely 
inaccessible.

I'm changing the code involved to use the original proxied class's classloader 
and protection domain.  So far I don't see any problems in geronimo or openejb.

            Class<?> cls = (Class<?>) unsafe.defineClass(proxyName, proxyBytes, 
0, proxyBytes.length, clsToProxy.getClassLoader(), 
clsToProxy.getProtectionDomain());

I've opened https://issues.apache.org/jira/browse/OPENEJB-1321 to provide a 
hook for any problems this may cause.  I'd really appreciate some review and 
informed criticism.

many thanks
david jencks

On Aug 4, 2010, at 12:22 PM, David Blevins wrote:

> Thinking it might be good to get more of us setup in the TCK.  Currently, 
> Geronimo is the only one with a TCK setup, but it is better than nothing.
> 
> With all the EJB 3.1 work there of course comes a ton of TCK work related to 
> getting that functionality to be spec compliant in the pass/fail sense.  As 
> Geronimo is the only one with a TCK setup it translates to Geronimo getting 
> stuck having to finish the EJB 3.1 development work.  Seems to make the most 
> sense to get the people doing EJB 3.1 feature involved in ensuring it passes 
> the TCK.
> 
> Any committer can request Java EE 6 TCK access via singing faxing or emailing 
> ([email protected]) this NDA:
> 
>  http://www.apache.org/jcp/ApacheNDA.pdf
> 
> 
> Anyway, here is the issue that prompted me to send this note.  Related to 
> @LocalBean support.  David J. poking at it currently, but any help is 
> welcome.  There will definitely be many more like this.  Having the most 
> people with access to the TCK as possible is probably a very good thing.
> 
> 
> Caused by: java.lang.LinkageError: loader (instance of  
> org/apache/xbean/osgi/bundle/util/BundleClassLoader): attempted  duplicate 
> class definition for name: "com/moon/sometest/SomeBean$LocalBeanProxy"
>       at sun.misc.Unsafe.defineClass(Native Method)
>       at 
> org.apache.openejb.util.proxy.LocalBeanProxyGeneratorImpl.createProxy(LocalBeanProxyGeneratorImpl.java:65)
>       at 
> org.apache.openejb.util.proxy.LocalBeanProxyGeneratorImpl.createProxy(LocalBeanProxyGeneratorImpl.java:48)
>       at 
> org.apache.openejb.util.proxy.LocalBeanProxyFactory.newProxyInstance(LocalBeanProxyFactory.java:27)
>       at 
> org.apache.openejb.core.ivm.EjbHomeProxyHandler.createProxy(EjbHomeProxyHandler.java:139)
>       at 
> org.apache.openejb.core.ivm.EjbHomeProxyHandler.create(EjbHomeProxyHandler.java:286)
>       at 
> org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:169)
>       at 
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:282)
>       at $Proxy52.create(Unknown Source)
>       at 
> org.apache.openejb.core.ivm.naming.BusinessLocalBeanReference.getObject(BusinessLocalBeanReference.java:34)
>       at 
> org.apache.openejb.core.ivm.naming.Reference.getContent(Reference.java:40)
>       at 
> org.apache.xbean.naming.context.ContextUtil.resolve(ContextUtil.java:61)
>       at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:116)
>       at 
> org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:605)
>       at 
> org.apache.geronimo.openejb.DeepBindableContext$ContextWrapper.lookup(DeepBindableContext.java:97)
>       at 
> org.apache.openejb.core.ivm.naming.IntraVmJndiReference.getObject(IntraVmJndiReference.java:39)
>       at 
> org.apache.openejb.core.ivm.naming.Reference.getContent(Reference.java:40)
> 
> 
> -David
> 

Reply via email to