Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4D0520E7.8080809@zeus.net.au>
Date: Mon, 13 Dec 2010 05:22:15 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: Standard Deployment Container [was:] Re: Jini	Community	Projects
 on Java.net WAS: Re: java.net
References: <AANLkTim-Zm6VOx2MNaL6FEche0wH6XQ0niNd0Atd5WO+@mail.gmail.com>
	 <4CECF4A7.5050507@zeus.net.au>	<4CF66617.7070208@wonderly.org>
	 <AANLkTim2235sTD1p6cVvU6ZyWzwLygt3DOy51SdNznfX@mail.gmail.com>
	 <4CF9698B.3020808@wonderly.org>
	 <AANLkTi=Z=OAJ0VoFPMVTmxjNCmSOM3d4Yd05OiX7qn7w@mail.gmail.com>
	 <4CFF7270.3040305@zeus.net.au>
	 <AANLkTinuEXYSRoLaoo4mNWpRUxG_ebMxL4zeNKLu18w9@mail.gmail.com>
	 <4D0040F3.90401@zeus.net.au>
 <1291919962.22111.37.camel@cameron>	 <4D047C2B.2080208@zeus.net.au>
 <1292175777.7994.15.camel@cameron>
In-Reply-To: <1292175777.7994.15.camel@cameron>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Greg Trasuk wrote:
> On Sun, 2010-12-12 at 02:39, Peter Firmstone wrote:
>   
>> Yes, I had noticed the container, interesting.
>>
>> Do you think it's possible to organise runtime ClassLoader's so Jini's 
>> API, Java and the Service API are loaded with Java's application class 
>> loader, while all  implementations are loaded into separate child class 
>> loaders?  If we do this, we can keep, service implementations, client 
>> code and proxy's in separate namespaces, forcing them to cooperate using 
>> only Java, Jini's API and Service API.  Sort of like having separate 
>> Classpath's for each, many are compiled separately so it makes sense if 
>> they each bring their own lunch and don't step on each others 
>> implementations and libraries etc.  
>>     
>
> Goes without saying...Also that we don't put every single jar file in
> the codebase annotation.  Usually it's only the "-api" and "-dl" jar
> files, although there might be plain libraries as well.
>   

If done properly, the api exists at the client, so we shouldn't need to 
annotate it, I proposed a way of extending Service API in

https://issues.apache.org/jira/browse/RIVER-341

This would allow additional classes not present at the client to be 
loaded into the proxy's class loader.  Since the deployed client doesn't 
have these classes, it only interacts using the Service API.

If there is a buggy implementation class in the original Service API 
installed in the client, the extended service API can provide an 
implementation class that extends and overrides the object method with 
the bug, the client only see's the service API class, while it uses the 
implementation class. Polymorphism.

>   
>> Eg a proxy should bring with it any 
>> additional libraries it needs and not rely on them being present at the 
>> client.  
>>     
>
> That's automatically handled by the rmi classloader
> (PreferredClassLoader I believe) and the appropriate codebase
> annotations.
>
>   
>> Application libraries shouldn't be visible to the proxy.  Sort 
>> of like Preferred Classes, but automatic without configuration.
>>
>>     
> That's actually up to the application author; in many cases, there is a
> need to have a dependent library available locally (e.g. for
> business-domain object classes).  The PreferredClassLoader mechanism
> used by Jeri allows the proxy to require a remotely downloaded class
> where it's absolutely necessary.
>
>   
Sounds like that library should be loaded with the same classloader as 
the Service API.  Is it typical in this case that the Service API 
contain a parameter or return class that is part of a business domain 
library?

If Service API depends on anything other than Jini & Java, that also 
needs to be included with the service API.

I'd like to provide a mechanism or encourage a practice to load 
application (implementation) classes into a child class loader, with a 
separate name space to proxy's  or other service implementations.

Tell me what you think?

http://labs.oracle.com/techrep/2006/smli_tr-2006-149.pdf

Cheers,

Peter.