river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Standard Deployment Container [was:] Re: Jini Community Projects on Java.net WAS: Re: java.net
Date Sun, 12 Dec 2010 07:39:23 GMT
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.  Eg a proxy should bring with it any 
additional libraries it needs and not rely on them being present at the 
client.  Application libraries shouldn't be visible to the proxy.  Sort 
of like Preferred Classes, but automatic without configuration.



Greg Trasuk wrote:
> On Wed, 2010-12-08 at 21:37, Peter Firmstone wrote:
>> Usability is a tough problem we need to solve, I recall Dan Creswell 
>> highlighted some relevant issues.    If your looking at all the 
>> different down stream projects and want to get their cooperation for 
>> some common functionality, we'll need to get some community buy in.  
>> These people are probably more aware of the pitfalls and I think we need 
>> their insight.
>> There's all the different containers too.  Perhaps it's time we have a 
>> standardised deployment container?  So users can choose and migrate 
>> among any of the downstream projects or our own in house simple version 
>> (that supports what you're working on) without lock in.
> So, I've been working on a clean-room implementation of the Surrogate
> spec.  The work so far (mainly some building blocks) is in Subversion
> under jtsk/skunk/surrogate.
> I concluded early on that hosting Surrogates was really a subset of
> hosting plain old services.  As a result, the emerging architecture is
> that of a container that manages the classloaders and codebase servers,
> but that has a pluggable deployment architecture that can support
> surrogate packages, "starter-style" packages or other deployment units.
> To some extent, this container is "Harvester 2.0"; it reflects my unease
> with going through and restructuring the Harvester code for Apache
> release (I had thought about contributing Harvester, but decided to do
> this new surrogate container instead).
> I am envisioning a deployer that would support definition of services
> using annotations, much like EJB3 supports,  e.g.
> public interface HelloInterface {
>     public String sayHello(String name) throws IOException;
> }
> @Service
> public HelloService implements HelloInterface {
>     public String sayHello(String name) { return "Hi there " + name); }
>     /* @Proxy says "Inject my exported proxy here, please!" */
>     @Proxy 
>     HelloInterface myProxy=null;
> }
> You would create your services, pack them into a jar file (with an
> appropriate manifest) and copy the jar file into the deployment
> directory.  The deployer then goes through the jar file looking for
> @Service annotations and exports them.
> The container will also host (with all the codebase crap handled!)
> instances of the River infrastructure services (Reggie, Mahalo,
> Outrigger, etc).  Plus it appears that enabling it for JMX monitoring
> and management will not be awfully difficult.
> The goal, much like Harvester, is one-shot deployment, with a
> programming model that will not seem alien to servlet or EJB
> programmers.
> So, stand by, the container is starting to come together.  Once it's in
> a form that can host Reggie and deploy a service or two, I'll let you
> know.  At that point, I suppose we'll want a catchy name...
> Cheers,
> Greg.

View raw message