| Classloader problem when deserializing [message #707526] |
Mon, 01 August 2011 19:18  |
 stormweaver 
Messages: 3
Registered: August 2011 |
Junior Member |
|
|
Hi there.
I'm relatively new to OSGi and have been facing a problem, which I assume has to do with the classloaders. Here's my situation:
My goal is to serialize and deserialize a message(object), where the code for deserialization is on a different bundle than the one containing the class being serialized.
I have two bundles B1 and B2. The class to be (de)serialized is in B2.
A class (say C1) in B1 has the code for deserialization:
C1.received(byte[] buf, int offset, int length)
This class is extended in B2, to derive another class C2.
In B2, I have a object of type C2 for receiving serialized buffer, and I called
c2.received(buf, offset, length)
I get a ClassNotFound error inside that method while trying to deserialize, eventhough this method call is being made in B2.
When I moved the code for deserialization from the abstract class C1 to C2, it worked fine. Hence, I've come to the conclusion that when calling methods from superclasses that are on a different bundle, a "context switch" or something like that occurs (I'm not sure about the term used)
However, I need the deserialization code to be in the superclass C1 in bundle B1, to avoid duplicating it into all subclasses. How can I get this to work?
I tried using Eclipse-BuddyPolicy: dependent in B1's manifest, but that didn't do it either. Or do I need to start some bundle to get BuddyPolicy to work? Currently I'm only using the org.eclipse.osgi jar and my two jar files B1 and B2.
Any suggestions please 
|
|
|
| Re: Classloader problem when deserializing [message #707882 is a reply to message #707526] |
Tue, 02 August 2011 06:37  |
|
Am 01.08.2011 21:18, schrieb stormweaver:
> However, I need the deserialization code to be in the superclass C1
> in bundle B1, to avoid duplicating it into all subclasses. How can I
> get this to work?
Are you using vanilla Java serialization/de-serialization (i.e.
ObjectInputStream)? If yes then one possible way is to extend
ObjectInputStream with an implementation that overrides
"resolveClass(ObjectStreamClass)". In that method you should delegate to
the appropriate ClassLoader or to Bundle.loadClass(String) (likely the
class loader/bundle of your subclass).
There is such an implementation available in Apache Commons IO.
org.apache.commons.io.input.ClassLoaderObjectInputStream
Buddy-ClassLoading is another way but that is Equinox only.
-Gunnar
--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
|
|
|
|
|
Powered by
FUDForum. Page generated in 2.41861 seconds
] 
Search
Help
Register
Login
Home
