river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Develop new spec for RMIClassLoader replacement
Date Sun, 26 Aug 2012 14:17:41 GMT
See comments interspersed...

On Sun, 2012-08-26 at 04:53, Peter Firmstone wrote:
> There are some notable conditions that may exist in modular environments.
>    1. Lets get this out of the way first: Preferred proxy classes are
>       implementation classes, the modular environment has no place
>       managing proxy private implementation classes.
>    2. In addition to the marshaled smart proxy implementation,
>       Serialized objects will be transferred between remote hosts and
>       these may not belong to the proxy preferred class list, instead
>       they will belong to the Java or Jini platforms, or the Service
>       API, a local modular environment requires these objects be
>       instantiated by the correct class instance, which may reside in
>       different ClassLoaders.
>    3. Different versions of classes may be present locally in separate
>       ClassLoaders.
>    4. Resolving classes for objects a smart proxy refers to may not be
>       visible via traditionally expected ClassLoader hierarchy trees.  
>       These classes may need to be found by other means.  These classes
>       needn't be visible to the smart proxy, fields may refer to a
>       common super class or interface.
>    5. Service API must reside in a parent ClassLoader, so we need to
>       know super class names, to be able to nominate a suitable parent
>       ClassLoader for a smart proxy.
Small point - #5 isn't quite true, although that's the way most
containers, Jini and otherwise, seem to operate.  For instance, in most
servlet containers, the servlet API is in a parent classloader to the
servlet itself.  Similarly, in the Jini Starter utility, the River API
classes are in a parent classloader.  This is usually done for the
convenience of the container - it allows the container to access the
same classes that the application does, without needing to use

The correct, and slightly looser, constraint is that classes and
interfaces used in the API must be visible to application classes.  They
could be in the same classloader as the applicaton classes.  In the
River container I'm working on in /skunk, the service API classes are
actually in the same classloader as the application (much like the
application would include the interface classes for a user-written
service).  The container communicates with the application using the
Reflection API, and doesn't share any classloaders with the contained
applications (except the system CL, of course).

I guess what I'm saying is that it's hazardous to assume any particular
classloader hierarchy.  The classloader used to house the proxy should
probably just have the application's context class loader as its parent.

> This won't be so hard to implement if we have a ClassLoader registry and 
> we know super class names and version information, this information is 
> currently not annotated with the Object stream.
I don't think versions are required.  Simply load any preferred classes
from the codebase url that the remote object provides.

> A modular JRE won't be released until Java 9, so there's no hurry, but 
> to ensure we don't overlook any important details, lets create a related 
> Jira issue to develop a spec.
> Cheers,
> Peter.



View raw message