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 Sun, 26 Aug 2012 18:11:12 GMT

On Aug 26, 2012, at 9:17 AM, Greg Trasuk <trasukg@stratuscom.com> wrote:

> 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
> reflection.
> 
> 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 is the flexibility that I think we need to focus on.  We need to think about class origins,
and any time/place that River is interacting with class loading, we should try and evaluate
how that can be the least troublesome.  In some cases, no-flexibility can be less trouble.
 100 interfaces and abstract classes don't always make the best programming environment. 
One way to do things, which works well, can be a good thing.

> 
>> 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.

I'd like to keep "Versioning" completely out of what River considers as part of the "platform".
 The plugability of class loading should not hinder the use of versioning.  It may be a good
idea to put down some sentences which represent the features which we all agree versioning
is represented by.  Then we can keep River from prohibiting those things as a choice.

Gregg


Mime
View raw message