Classloading issue with OSGI bundles/Eclipse plugins (ClassN

[ajwhitney]

I am receiving a ClassNotFoundException whenever I remotely execute a method on a session bean which returns a custom type from an OSGI bundle. Methods which return primitives or standard types (i.e. String) work fine. The code works fine when called from a web application and/or a simple command-line application so I'm pretty sure the issue isn't one of incorrect/incomplete client libraries.

It appears as though this problem is related to the way the remoting mechanism loads classes and how that interacts with the classloading scheme of the OSGI runtime.

I set the current thread's context classloader to the main plugin's classloader. This works around a similar issue I was having with the way RMI was loading classes (preventing me from performing JNDI lookups for my EJBs). I'm guessing that the remoting mechanism doesn't use the context classloader.

Is there a way to specify which classloader the remoting mechanism uses? Any information regarding how the remoting mechanism loads classes would be very helpful.

This problem probably isn't just an EJB3 issue. If there is a more appropriate forum to which I should post this topic, please let me know.

Thanks,
A.J. Whitney
[e-mail]

A sample stack trace is included below in the event that helps track down where the classloading is failing:

Caused by: java.lang.ClassNotFoundException: com.clearprogress.c2.core.impl.Person
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:405)
at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:350)
at org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.loadClass(AbstractClassLoader.java:78)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:574)
at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:102)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1538)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1693)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:107)
at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1753)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1711)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1912)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1713)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:73)
at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:242)
at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:112)
at org.jboss.remoting.Client.invoke(Client.java:226)
at org.jboss.remoting.Client.invoke(Client.java:189)
at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:41)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:40)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:41)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:88)
... 24 more

[ajwhitney]

Just for additional information...

As long as the JBoss client libraries and the custom type returned from the session bean are in the same bundle, things appear to work fine. It just doesn't work nicely if the JBoss client libraries are in one bundle and the custom type is in another.