river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Develop new spec for RMIClassLoader replacement
Date Sun, 26 Aug 2012 22:12:55 GMT
Gregg,

If you want to use Netbeans RCP, then why not consider making everything OSGi-able? We are
using a Netbeans RCP front end on a project I'm working on now (with a Rio-backend that uses
a custom RMIClassLoaderSpi that does artifact resolution for an artifact URL, goodbye http
codebases and good riddance:) ), and from what I see, you either need to wrap everything up
and turn it into an OSGi module, or go whole-hog and make everything OSGi (its all or nothing).


Dennis

On Aug 26, 2012, at 211PM, Gregg Wonderly wrote:

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