river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GREGG WONDERLY <gregg...@gmail.com>
Subject Re: Develop new spec for RMIClassLoader replacement
Date Thu, 23 Aug 2012 14:41:26 GMT

On Aug 23, 2012, at 5:57 AM, Simon IJskes - QCG <simon@qcg.nl> wrote:

> On 19-08-12 14:09, Peter Firmstone wrote:
> 
>> Thoughts?
> 
> What is the main driver for the RMIClassLoader replacement?

The technical details, are/were that the default behavior of PreferredClassProvider and RMIClassLoaderSPI,
together said that the parent class loader of the unmarshalled objects' URLClassLoader, which
was created using the annotation returned by RMIClassLoaderSPI, was null, or otherwise known
as the system class loader.

In netbeans, the correct parent class loader, is the class loader of the invoking class, because
the system class loader is empty of anything except the basic netbeans platform classes which
are enough to start module loading from the other class loaders which are created/associated
with the "modules" that make up the netbeans application (whether or not it's the actual IDE
application itself).

So, I needed to augment the behavior of PreferredClassProvider and replace the RMIClassLoaderSPI
implementation with a new one.  The problem is, that you can't change the netbeans "classpath",
at startup, with a "module".  You have to rewrite all kinds of "configuration" and such and
thus you can't plug in a different RMIClassLoaderSPI, at all.

Thus, I decided to do what developers do best to solve software problems.  I added another
layer of indirection between Jini/River and the RMIClassLoaderSPI so that we could replace
the behavior of RMIClassLoaderSPI programmatically, at runtime.  I augmented PreferredClassProvider
to call out to this new layer as well, to access the details about which parent class loader
should be used.

Additionally...

When I was doing this, I was also imagining changes to how unmarshalling would be done, and
so I wanted to be able to replace the entire behavior of RMIClassLoaderSPI in the river source,
to potentially provide the start of a layer which would allow this to be done. 

In the old days, we had ObjectSpace's Voyager in the RPC community, and they provided a seamless
behavior of sending objects between VMs.  It just worked.  The codebase annotation available
through the RMIClassLoaderSPI getAnnotation() mechanisms, was passed on to the recipient VM
so that it could load the same vintage class definition as was used by the sender.

This, of course doesn't always "just work", but for many more applications, then not, it provides
a more dependable mechanism because versioning all but disappears.

Gregg Wonderly
Mime
View raw message