Hi, i did a really ugly quick fix using ThreadContextClassLoader and it is working (using resolveClass for ObjectInputStream).
I say ugly because it is still based on class name [not OSGI compliant] but it validates the ThreadContextClassLoader "Workaround". Thanks Regards hervé On Tue, Apr 24, 2012 at 5:45 PM, Hervé BARRAULT <[email protected]>wrote: > Hi thanks for the explanation about the Class.forname usage (It is clear > when you don't forget that you can manipulate at the same classes in > different versions). > > I think, it could be a good idea that the OSGi container provides a > serialization/deserialization service or tool which covers the constraints > of OSGi. > > Regards > Hervé > > > > On Tue, Apr 24, 2012 at 5:22 PM, Christian Schneider < > [email protected]> wrote: > >> 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 >> >> >
