Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4C1F8B51.6030208@cox.net>
Date: Mon, 21 Jun 2010 10:54:57 -0500
From: Gregg Wonderly <gergg@cox.net>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Service API, class visibility, isolation and garbage collection
 - ClassLoaders
References: <4BF7B43C.2060302@zeus.net.au>
 <AANLkTinX1iNbJsvSkDtX5mIusEnTc9SJTRuEBvsB4RKW@mail.gmail.com>
 <F9941221-96E5-4ECA-8DB2-A3EB8D71410B@gmail.com>
 <77F1E32F67C8D5479858C0C7E93EB465577AF2@WAL-MAIL.global.avidww.com>
 <4BFB3741.4080408@zeus.net.au>
 <FCEBE007-7AAE-420C-830F-F157442E5453@gmail.com>
 <4BFB68B3.8070403@zeus.net.au>
 <EA4B7608-E1B2-4FC0-BC15-E1537243EE99@gmail.com>
 <4BFC58CD.5070901@zeus.net.au>
 <6CE2CB17-96E3-4801-B859-A394B54EBAC7@gmail.com>
 <4BFCB4CD.7010809@zeus.net.au> <4BFCBDC2.4000602@zeus.net.au>
 <4BFD0592.2000106@zeus.net.au>
 <FCD5149B-45D6-43A0-9611-91C3A42A9F81@gmail.com>
 <4BFD3BBA.7060504@wonderly.org> <4C01FF7F.9050300@zeus.net.au>
In-Reply-To: <4C01FF7F.9050300@zeus.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Getting back around to some of these, hopefully no confusion...

Peter Firmstone wrote:
> Hi Gregg,
> 
> Sorry I missed this earlier, have a look at my latest messages, they 
> might provide some more background to my thoughts.
> 
> Mike Warres has a good example of when the existing mechanism causes 
> codebase annotation loss and type conflicts on page 23 of his paper 
> "Class Loading Issues in Java RMI and Jini Network Technology".
> 
> https://issues.apache.org/jira/secure/attachment/12413650/Java+Classloader+issues+relating+to+Jini+smli_tr-2006-149.pdf 
> 
> Because the Service API is loaded from the local file system and isn't 
> dynamically downloaded, it may not have an annotation, I'm thinking 
> about creating a new URL scheme, that provides information about all Jar 
> files, whether local or downloaded dynamically, such as jar name and 
> version annotation.  This should help people who wish to provision their 
> codebases.

For me, the important thing to understand about class resolution/loading, is 
that there are two distinct issues.  First, do you have the correct version of 
the class somewhere in the class loading system in use, and Second, if the right 
version or no version is available, do you have a way to go look for a 
definition that would be the right version to use?

ClassLoaders have historically been the domain of issue #1.  Issue #2 has been 
dealt with in a surprisingly large number of ways.  Serialization annotations 
that MarshalledObject et.al. provide one way to deal with #2.  But we also have 
later development of things like OSGi, Maven and other packaging systems which 
include ways to declare or facilitate resolution of missing dependencies.

RMIClassLoaderSPI is the pluggable way to deal with the String annotations on 
classes.  It can facilitate a wide number of possibilities.  The predominate 
issues is that it doesn't include an "implementation" indication in concert with 
the String value, so you don't know how to "delegate" to other mechanisms to 
make use of that String value in a "varied" way.

It seems to me that if we do something with a new RMIClassLoaderSPI 
implementation.  My changes add no real value other than facilitating the 
addition of another implementation that is offered remotely or through some 
other path.  What we really need is the ability to look at the annotation and 
use it intelligently to ask a factory mechanism to use it to create a class loader.

> Note I haven't had any thoughts about removing PreferredClassProvider, 
> but I'm thinking about another ClassLoader structure, although I'm prone 
> to changing my mind as I struggle to understand it all.  I haven't got 
> any implementations, yet, still working it all out.

PreferredClassLoading allows you to fix code that is generally used across an 
application "suite", by overriding the use of something in the classpath with 
something you provide in your -dl.jar (or other codebase content) by making it 
preferred.  I find this mechanism extremely useful in my service UI client that 
has the same classes as all my UIs use for Swing and AWT stuff.  If I need 
additional functionality or to fix something that only the UI of a service 
needs, then I can make that class preferred and not have to update all of my 
service UI client instances.  Mobile code solutions are very convenient.

Gregg Wonderly

> Gregg Wonderly wrote:
>> I have a Jini based application that is a content based router system 
>> for satellite networks.  There are multiple servers running with comms 
>> cards, and the ServiceUI needs to see all of them at once, because I 
>> use transactions to commit data changes to all servers.  In this case, 
>> one clients ServiceUI must lookup all of the services, ignoring 
>> itself, and then get the service proxies to work with.  All of the 
>> services proxies need to share interfaces and data classes that are 
>> commonly exchanged.
>>
>> I didn't need a different kind of classloader tree, I just needed to 
>> make sure that the parent class loader of the RMIClassLoaderSPI was 
>> the ClassLoader of the client (The context ClassLoader which is a 
>> PreferredClassLoader), which was already happening.  All the other 
>> service instance unmarshalling would in fact make use of the 
>> PreferredClassLoader, so that versioning could be done by preferring 
>> classes, for example, and each services preferred classes would be 
>> honored.
>>
>> There is only one -dl.jar involved in the commonality aspects of the 
>> involved Classes.  I could break the common classes into a separate 
>> jar, but I have not done that, yet.
>>
>> This type of application must be restarted fairly rarely, so class 
>> compatibility is a very key issue.
>>
>> Peter, can you provide a more specific example of when you think the 
>> structure you are proposing would be valuable, i.e. the existing 
>> mechanism would break?
>>
>> Gregg Wonderly
>>
> 
>