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
>
>

Reply via email to