SpringSource ActiveMQ, either I'm doing it wrong or Bundle issue

[soks86]

Hi,

I'm using the spring JmsInvokerProxyFactoryBean to invoke some dao methods from an OSGi server to a regular ApplicationContext application on another server.

I'm using ActiveMQ and am running into an issue but I'm not sure if it's me or the ActiveMQ bundle I'm using from the springsource repository.

Inside of org.apache.activemq.command.ActiveMQObjectMessage. getObject() line: 177 I'm getting an exception that reads:

[2009-06-14 16:13:42.154] AWT-EventQueue-0                                                               System.err E Exception in thread "AWT-EventQueue-0" org.springframework.remoting.RemoteAccessException: Could not access JMS invoker queue [queue://traderQueue]; nested exception is javax.jms.JMSException: Failed to build body from bytes. Reason: java.io.IOException: org.springframework.remoting.support.RemoteInvocationResult in ServerBundleClassLoader: [bundle=com.springsource.org.apache.activemq_5.2.0]

If I trace it out to see what's going on I get:

com.springsource.server.osgi.framework.ServerClassNotFoundException: org.springframework.remoting.support.RemoteInvocationResult in ServerBundleClassLoader: [bundle=com.springsource.org.apache.activemq_5.2.0]

So does this mean the ActiveMQ bundle needs to import "org.springframework.remoting" or am I supposed to somehow import it?

I see that it imports org.springframework.context which contains org.springframework.remoting... so is this something on me? I do know that hte org.springframework.context bundle is ACTIVE.

[Glyn Normington]

The problem seems to be related to deserialising an object with a particular type (it happens to be a Spring type in this case, but there doesn't seem to be anything special about that) in an environment which cannot load the type.

My guess is that this is some class loader issue or possibly a deserialisation issue in the JRE. I'd like to find out how ActiveMQ uses deserialisation to know whether it could feasibly cope with situations like this - I'll follow up with someone in the company who is an expert in ActiveMQ.

If you have the time, it would be helpful if you could boil the problem down to a simple testcase and raise a JIRA. Note that this problem is unlikely to reproduce using a single JVM as the serialisation/deserialisation is 'optimised' away in the local case. (Actually this is not an optimisation as it is semantically quite different, but that's another story!)

Meanwhile, it would definitely be wrong to add an import to the ActiveMQ bundle, but you might try attaching a fragment to the ActiveMQ bundle and put the import in the fragment. This isn't a particularly robust solution as you have to know all the packages that might be needed for deserialisation, but it might help you avoid the problem until a robust fix or workaround is available.

[soks86]

Glyn! Thanks for all the articles!

I'm confused... surely many people use JMS. This looks like a normal call for the ActiveMQ library and from what I see a class type has to be known to deserialize it (how else could you?). So shouldn't this occur for anyone who uses ActiveMQ (unless they are only sending standard Java types)?

Unless I'm crazy and most users send Strings through JMS... I suppose this is the first time I'm not using a String type.

I'll get that test case for you, probably won't be a simple unit test but I'll do my best, some type of Spring test should do it.

[soks86]

Glyn,

I traced it (developing test case) and it goes into the Java libraries to de-serialize and when it tries to look up the class it can't (not in the bundle).

Do other people really just use string for JMS in OSGi? Is that what is normally used with JMS?

[Glyn Normington]

It turns out ActiveMQ uses the thread context class loader when deserialising objects.

So let's consider your application bundle that is triggering the deserialisation. Is it a single bundle or part of a PAR file? If it's a single bundle, does it import the package org.springframework.remoting.support?

Other people probably have suitable imports, I guess.

[soks86]

protected Class resolveClass(ObjectStreamClass classDesc) throws IOException, ClassNotFoundException {
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        return load(classDesc.getName(), cl);
    }

Yeah, I see that... now that you mention it.

Turns out it was three more imports I needed, so when I tried one I didn't realize the error message changed.

Thanks for the help, I'll keep in mind not to trust a Bundle to use it's own class loader.