[RT] Classloaders in relation to MarshalledObject

<preface>[RT] stands for Random Thought(s), and refers to an inoherent
collection of thoughts that may (or not) trigger thinking of other
individuals within the community.</preface>


AFAICT, if I marshall an object that has a classloader hierarchy, the
unmarshalling of that object will not restore the classloader hierarchy of
the original. It leads to 'corrupt' classloader situations in the
unmarshalled case of the objects, and makes marshalling of transportable code
fairly complicated in certain scenarios.
It is of course fairly doable with todays API, as the marshalling code will
not be able to pick out what classloaders are relevant to the marshalled
object.

Let's look at a simple example;

I often end up creating reloadable code by using the standard classloader
mechanism, and separating the API from the Impl (sometimes an additional
management CL as well in between). So for one particular "component" I would
have a pair of;

     +--------+
     | API-CL |
     +--------+
          |
     +---------+
     | Impl-CL |
     +---------+

But often the Impl CL is a composition of further API/Impl Classloader pairs.

Furthermore, the 'users' of the API will be branched off in parallel to the
Impl-CL, so that it is not possible for the API users to downcast to
implementation classes.

My build system will ensure that the API URL is located at the "right
classloader level", and only there.

AFAICT, if I marshall an implementation class, only the URL for the Impl-CL
will be stored in the marshalled object, and that can be tricky to handle.

If there was a MarshalledObject constructor that took a ClassLoader array,
then it would be possible to store the required classloader hierarchy, and
re-establish it on unmarshalling.
The unmarshalling phase should possibly allow for some manipulation of the
classloader hierarchy, or perhaps just allow me to query for the information,
to create my own classloader, which is then passed as an argument to a get()
method.

Or is all of this totally out of the scope of serialization, and I should roll
my own generic solution?


Any thoughts?


Cheers
Niclas

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html