RE: WebStart/JMX use cases (was RE: [equinox-dev] April 8th meeting minu

["Martin Buechi" <Martin.Buechi@xxxxxxxxxxxxxxx>]

All,

>  > 4. Standalone server applications with CORBA or RMI interface. Usage of
> the
>  > Eclipse plugin framework is straightforward in this case.
> 
> 
> We have implemented something like this and observed a number of problems.
> The
> most problematic one, I think, is the usage of the Java serialization
> mechanism
> for RMI parameter objects, because the serialization mechanism does not
> "know"
> from which plugin a specific class came from (that is used for an object
> inside
> the stream). There are several workarounds for this (e.g. a special
> context
> class loader for the thread that does an overall class search) but I don't
> know
> a real clean solution for this.
> One solution might be to extend the ObjectInput/OutputStreams to store
> additional information for each class into the stream (plugin_id, for
> example),
> but I don't know of any possibility to substitude the object streams that
> are
> used for RMI.
> 
> Any idea?

Assuming that the defining classes of all objects that need to be
deserialized can be found in the parent, self, or the prerequisites of the
code that deserializes the data, I think the following should work:

- ObjectInputStream: Create a subclass of ObjectInputStream and override
ObjectInputStream.resolveClass() to use the P-S-P resolution of the plugin's
class loader (rather than the Java default P-S).

- RMI: Implement and register a RMIClassLoaderSpi (JDK 1.4) that uses the
P-S-P resolution of the plugin's class loader. We do that in our own plugin
framework and it works just fine.

If data from other plugins has to be deserialized, a global search through
all plugin class loaders should work, provided that each class is defined
only once (otherwise we get into a dilemma). This is not a requirement as of
now, presumably to allow alternative versions with P-S-P rather than P-P-S
class resolution and to allow the independence assumption between plugins
from different vendors. In our environment we can satisfy this assumption.

Yet another approach would be to use a class loader that has the classes of
all objects that need to be deserialized in its classpath and use this,
rather than the system boot class loader, as the parent for plugin class
loaders. Depending upon the setup, this may or may not be feasible.

Let me make an additional point that relates to this thread but is not a
direct response to the above: The need for custom class loaders to support
the P-S-P class loader model is the reason why an Eclipse plugin-based
application deployed via WebStart cannot run in an untrusted environment
(unless there are not duplicate class definition).

Regards,

Martin

P.S. I forgot to mention that reloading of plugins in Eclipse is another
Equinox interest of mine. I doubt that I will have any resources to
contribute to this, but I would definitely like to have it.

BEGIN:VCARD
VERSION:2.1
N:Buechi;Martin
FN:Martin Buechi, Ph.D.
ORG:ChoiceMaker Technologies
TITLE:Chief Software Architect
TEL;WORK;VOICE:(212) 905-6033
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;41 East 11th Street=0D=0A11th floor;New York;NY;10003;United States of Ame=
rica
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:41 East 11th Street=0D=0A11th floor=0D=0ANew York, NY 10003=0D=0AUnited Stat=
es of America
URL;WORK:http://www.choicemaker.com
EMAIL;PREF;INTERNET:Martin.Buechi@xxxxxxxxxxxxxxx
REV:20010622T032847Z
END:VCARD