Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: domain of greggwon@gmail.com designates
 209.85.160.43 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
Subject: Re: Develop new spec for RMIClassLoader replacement
From: Gregg Wonderly <greggwon@gmail.com>
In-Reply-To: <1345990661.7614.16.camel@cameron>
Date: Sun, 26 Aug 2012 13:11:12 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <C771E0B4-DC5E-4EF1-878E-811EE3C093BE@gmail.com>
References: <5030D778.6030609@zeus.net.au> <50360C90.4000004@qcg.nl>
 <503627FF.10405@zeus.net.au> <1345746340.2530.220.camel@cameron>
 <A974ACD2-DA7D-4156-AA65-F6439F0A4BE0@gmail.com>
 <5039E41E.7050702@zeus.net.au> <1345990661.7614.16.camel@cameron>
To: dev@river.apache.org


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

> See comments interspersed...
>=20
>=20
> On Sun, 2012-08-26 at 04:53, Peter Firmstone wrote:
>> There are some notable conditions that may exist in modular =
environments.
>>=20
>>   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. =20=

>>      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.
>>=20
> 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.
>=20
> 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).
>=20
> 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.

>=20
>> This won't be so hard to implement if we have a ClassLoader registry =
and=20
>> we know super class names and version information, this information =
is=20
>> currently not annotated with the Object stream.
>>=20
> 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