Hi Hervé,
does not look like ObjectInputStream is really doing this cleanly. It
just uses Class.forname which is not good in the OSGi case.
You can try to set the ContextClassloader like this before calling the
deserialization code:
Thread.currentThread().setContextClassLoader(YourSerializedClass.class.getClassLoader());
The context idea only works when you do the serialization code yourself.
It would just be a List<Class> with the classes to work with. So
you could instantiate a class by classList.get(num).newInstance();
Btw. this is the best solution in OSGi whenever possible. Just do not
use class names in String form and instead directly use Class objects
that you initialize in
the bundle that already has access to this class.
Peter Kriens wrote in one of his blog entries that in OSGi there is not
a simple class name as you may have different versions of the same class
in the system. So a class name is only unique when you also specify the
classloader. Using the Class object in the first place completely avoids
this problem.
Christian
Am 24.04.2012 16:52, schrieb Hervé BARRAULT:
Hi,
thanks for the answer.
The deserialization code is like this :
final byte[] byteData = Base64.decodeBase64(dataStr);
ByteArrayInputStream bout = null;
ObjectInputStream oos = null;
try {
bout = new ByteArrayInputStream(byteData);
oos = new ObjectInputStream(bout);
toReturn = oos.readObject();
} catch( ...) {
} finally {
}
With the ObjectInputStream there is no class loader parameters but
some resolver (i will check this way).
For the second case, do you have an example of "class context injection" ?
Regards
Hervé
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
