river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Standard Deployment Container [was:] Re: Jini Community Projects on Java.net WAS: Re: java.net
Date Sun, 12 Dec 2010 17:42:57 GMT

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.

> 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

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

> Cheers,
> Peter.

View raw message