Deserialize Objects without original classloader

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Deserialize Objects without original classloader

Cedric Reichenbach
Hi everybody,

I'm using XStream to serialize objects before sending them into a
different JVM. Until now, I the JVMs were running on the same machine
and I knew the class path of the objects, so I could create custom
ClassLoader knowing all necessary directories and provide it to XStream.

However, now I'm trying to send those objects to a remote application,
which doesn't have any information about those object's classes. Since I
would like to avoid passing around class files, is there a way of
deserializing objects with XStream without their class files?

Regards,
Cedric

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Deserialize Objects without original classloader

Jörg Schaible-3
Hi Cedric,

Cedric Reichenbach wrote:

> Hi everybody,
>
> I'm using XStream to serialize objects before sending them into a
> different JVM. Until now, I the JVMs were running on the same machine
> and I knew the class path of the objects, so I could create custom
> ClassLoader knowing all necessary directories and provide it to XStream.

You mean, your clients were no compiled against the types you have
serialized with XStream and you did setup a classpath on the fly, because
you knew the location of the class files?
 
> However, now I'm trying to send those objects to a remote application,
> which doesn't have any information about those object's classes. Since I
> would like to avoid passing around class files, is there a way of
> deserializing objects with XStream without their class files?

XStream works like Java serialization, just with XML as data representation.
To deserialize, XStream has to instantiate the classes and requires
therefore the class files. With a different set of converters and/or XStream
setup you may deserialize the XML into a differnt set of objects, but I
guess this is not what you're up to.

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Deserialize Objects without original classloader

Cedric Reichenbach
Hi Jörg,

Am 21.10.2013 15:02, schrieb Jörg Schaible:

> Hi Cedric,
>
> Cedric Reichenbach wrote:
>
>> Hi everybody,
>>
>> I'm using XStream to serialize objects before sending them into a
>> different JVM. Until now, I the JVMs were running on the same machine
>> and I knew the class path of the objects, so I could create custom
>> ClassLoader knowing all necessary directories and provide it to XStream.
> You mean, your clients were no compiled against the types you have
> serialized with XStream and you did setup a classpath on the fly, because
> you knew the location of the class files?
>  
One side was compiled against those types, the other side not. To make
it a bit more clear: It's DoodleDebug
(http://scg.unibe.ch/wiki/projects/DoodleDebug), an Eclipse plugin which
receives objects to visualize in the user code, sends them to a server
(inside Eclipse JVM) visualizing them in an Eclipse view.

Now the current server application should be converted into a clustered
log, not running on the client's local machine anymore.

>> However, now I'm trying to send those objects to a remote application,
>> which doesn't have any information about those object's classes. Since I
>> would like to avoid passing around class files, is there a way of
>> deserializing objects with XStream without their class files?
> XStream works like Java serialization, just with XML as data representation.
> To deserialize, XStream has to instantiate the classes and requires
> therefore the class files. With a different set of converters and/or XStream
> setup you may deserialize the XML into a differnt set of objects, but I
> guess this is not what you're up to.
>
> - Jörg
Hmm, so I guess I'll have to find a way to provide class files to the
server side application...

Thanks for your help.

Cedric
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Re: Deserialize Objects without original classloader

Jörg Schaible-3
Hi Cedric,

Cedric Reichenbach wrote:

> Hi Jörg,
>
> Am 21.10.2013 15:02, schrieb Jörg Schaible:
>> Hi Cedric,
>>
>> Cedric Reichenbach wrote:
>>
>>> Hi everybody,
>>>
>>> I'm using XStream to serialize objects before sending them into a
>>> different JVM. Until now, I the JVMs were running on the same machine
>>> and I knew the class path of the objects, so I could create custom
>>> ClassLoader knowing all necessary directories and provide it to XStream.
>> You mean, your clients were no compiled against the types you have
>> serialized with XStream and you did setup a classpath on the fly, because
>> you knew the location of the class files?
>>  
> One side was compiled against those types, the other side not. To make
> it a bit more clear: It's DoodleDebug
> (http://scg.unibe.ch/wiki/projects/DoodleDebug), an Eclipse plugin which
> receives objects to visualize in the user code, sends them to a server
> (inside Eclipse JVM) visualizing them in an Eclipse view.

Looks interesting. If you like, I can add a link in
http://xstream.codehaus.org/references.html. It looks like DoodleDebug is
supporting http://jira.codehaus.org/browse/XSTR-510.

> Now the current server application should be converted into a clustered
> log, not running on the client's local machine anymore.

OK.

>>> However, now I'm trying to send those objects to a remote application,
>>> which doesn't have any information about those object's classes. Since I
>>> would like to avoid passing around class files, is there a way of
>>> deserializing objects with XStream without their class files?
>> XStream works like Java serialization, just with XML as data
>> representation. To deserialize, XStream has to instantiate the classes
>> and requires therefore the class files. With a different set of
>> converters and/or XStream setup you may deserialize the XML into a
>> differnt set of objects, but I guess this is not what you're up to.
>>
>> - Jörg
>
> Hmm, so I guess I'll have to find a way to provide class files to the
> server side application...

I'd go and transport the class files. A simple URLClassLoader at client side
using HTTP ...

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

AW: [xstream-user] Re: Re: Deserialize Objects without original classloader

Cedric Reichenbach
Hi Jörg,

Yes, an entry on the reference page would be great!

It kind of supports what's mentioned in your Jira issue, but instead of providing an XML, it graphically  visualizes an object.
Also, DD's usage is closer to System.out.println() than to debuggers, but you can actually make Doo.dle() calls on any object while the debugger is stopped through Eclipse's (kind of hidden and unknown) Expression view: http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fviews%2Fexpressions%2Fref-expressions_view.htm, which might also directly support your idea.

Cheers,
Cedric

-----Ursprüngliche Nachricht-----
Von: Jörg Schaible [mailto:[hidden email]]
Gesendet: Dienstag, 22. Oktober 2013 11:10
An: [hidden email]
Betreff: [xstream-user] Re: Re: Deserialize Objects without original classloader

Hi Cedric,

Cedric Reichenbach wrote:

> Hi Jörg,
>
> Am 21.10.2013 15:02, schrieb Jörg Schaible:
>> Hi Cedric,
>>
>> Cedric Reichenbach wrote:
>>
>>> Hi everybody,
>>>
>>> I'm using XStream to serialize objects before sending them into a
>>> different JVM. Until now, I the JVMs were running on the same
>>> machine and I knew the class path of the objects, so I could create
>>> custom ClassLoader knowing all necessary directories and provide it to XStream.
>> You mean, your clients were no compiled against the types you have
>> serialized with XStream and you did setup a classpath on the fly,
>> because you knew the location of the class files?
>>  
> One side was compiled against those types, the other side not. To make
> it a bit more clear: It's DoodleDebug
> (http://scg.unibe.ch/wiki/projects/DoodleDebug), an Eclipse plugin
> which receives objects to visualize in the user code, sends them to a
> server (inside Eclipse JVM) visualizing them in an Eclipse view.

Looks interesting. If you like, I can add a link in http://xstream.codehaus.org/references.html. It looks like DoodleDebug is supporting http://jira.codehaus.org/browse/XSTR-510.

> Now the current server application should be converted into a
> clustered log, not running on the client's local machine anymore.

OK.

>>> However, now I'm trying to send those objects to a remote
>>> application, which doesn't have any information about those object's
>>> classes. Since I would like to avoid passing around class files, is
>>> there a way of deserializing objects with XStream without their class files?
>> XStream works like Java serialization, just with XML as data
>> representation. To deserialize, XStream has to instantiate the
>> classes and requires therefore the class files. With a different set
>> of converters and/or XStream setup you may deserialize the XML into a
>> differnt set of objects, but I guess this is not what you're up to.
>>
>> - Jörg
>
> Hmm, so I guess I'll have to find a way to provide class files to the
> server side application...

I'd go and transport the class files. A simple URLClassLoader at client side using HTTP ...

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email