River container. was: Re: Thinking Aloud - fundamental challenges of jvm based distributed computing

[Greg Trasuk <tr...@stratuscom.com>]

Just between us...

The surrogate container I've been working on in
http://svn.apache.org/viewvc/river/jtsk/skunk/surrogate/
is only incidentally a container for surrogates.  It is really a
generalized container (Harvester v2, if you will) that happens to have
the capability (or will have anyway) to host surrogates.  It includes a
refactored version of ClassServer for the purpose of serving out the
classpath (although it could be replaced by a different web server if
necessary).  It also includes handling for hosting multiple service
applications under separate classloaders (in fact, not even the Jini API
is shared between them), and facilities for setting up separate
protection domains.

Current status is that it is just about able to host services designed
for deployment under the "ServiceStarter" paradigm, given that they are
packaged into a module with their appropriate classpath components.

To be entirely open, I haven't mentioned it so far, because I wanted to
have a working code drop, then propose it as a separate River
deliverable.  But since the topic of containers has showed up, I thought
I'd jump in.

For the record, I'm still opposed to the idea of defining "the"
Jini/River container; I believe the deployment environment is an
implementation detail, and nothing should prevent the current diversity
of containers and deployment approaches.  Having said that, one of our
persistent challenges has been the "rocket scientist" nature of getting
Jini/River up and running, and I believe that a container approach that
makes packaging service applications as simple as packaging web
applications will help immensely.

Cheers,

Greg.

On Tue, 2011-11-15 at 22:09, Niclas Hedhman wrote:
> On Wed, Nov 16, 2011 at 7:10 AM, Peter Firmstone <ji...@zeus.net.au> wrote:
> 
> > If we share only the Service API, Java and Jini Platform classes and
> > objects, then we minimise Java platform issues.
> >
> 
> I must have done something wrong in the past then, because that was always
> the case for me.
> 
> 
> > if the proxy is later transferred to another node in the network, the
> > codebase annotations have been lost because the classes were loaded by the
> > application class loader and resolved from the class path.  If the 2nd
> > remote node doesn't have the required classes on its classpath, it's game
> > over.
> >
> 
> Well, not necessarily. I used http:// URLs as the classpath for the entire
> application (yes, in its own child to the system classloader). Classpath
> annotations worked well. I could imagine that a River container has a
> webserver built--in and serving its own classes to needing clients.
> 
> 
> > This problem could be solved if the Classpath isn't visible to the proxy,
> > only the ServiceAPI, Java and Jini Platform classes, so developers don't
> > have to understand ClassLoader visibility and preferred classes and may
> > instead just focus on developing services and getting their OS and network
> > to support multicast discovery.
> >
> 
> Agree that it might help, or not...  If you are forced to understand
> classloader mechanics, I think you will learn to design better applications.
> 
> 
> > Some options:
> >
> >  1. Use the extension classloader
> >  2. OR Create a new child classloader, for the application and all
> >     libraries.
> >  3. OR Use a Subprocess
> >
> 
> Not sure I like any of those.
> 
> 
> Do you think it's time we work towards a standard container?  So that at
> > some point in the future all the downstream projects will be able to
> > support it as well as their existing container?
> >
> > What are the requirements for such a container?
> >
> 
> There a bunch of containers already, why not then discuss the pros/cons of
> each and see how what feedback there is.
> 
> 
> Cheers
> -- 
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
> 
> I live here; http://tinyurl.com/3xugrbk
> I work here; http://tinyurl.com/6a2pl4j
> I relax here; http://tinyurl.com/2cgsug