Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Peter <jini@zeus.net.au>
Reply-To: Peter <jini@zeus.net.au>
To: dev@river.apache.org
Subject: Re: Thinking Aloud - fundamental challenges of jvm based
	distributed computing
References: <4EC2F15C.8080208@zeus.net.au>
	 <CADmm+Ke-rOausSxHpP2hCXEDT9-p26fHrmG+2zYga8cXPAQrUg@mail.gmail.com>
	 <4EC475E8.1070000@zeus.net.au> <1321500435.9843.17.camel@cameron>
In-Reply-To: <1321500435.9843.17.camel@cameron>
Content-Type: multipart/alternative; boundary="=-OuIjvV8s16A91+TNGv8P"
Date: Thu, 17 Nov 2011 14:18:09 +1000
Message-Id: <1321503489.16664.5.camel@Nokia-N900-51-1>
Mime-Version: 1.0

--=-OuIjvV8s16A91+TNGv8P
Content-Type: text/plain; charset=utf-8
Content-ID: <1321503489.16664.2.camel@Nokia-N900-51-1>
Content-Transfer-Encoding: 8bit

See inline:
----- Original message -----
>
> On Wed, 2011-11-16 at 21:48, Peter Firmstone wrote:
>
> > +1 for Greg's new container too.    I've briefly looked at the code and
> > will have some time soon to study it more in depth.  Greg, is it
> > possible to integrate security and configuration as well?  Is some of
> > the stuff from Tim Blackman's Jini in a jar of use?
>
> The container is designed for:
> - pluggable deployers.  One for 'ServiceStarter' services, one for
> surrogates, perhaps one for an annotation-based service API, etc.  In
> fact it's a great platform for experimentation, as we can easily create
> deployers to test out various service-creation API approaches.  No need
> to standardize on any particular one.
> - pluggable configuration.  There is a 'core configuration'in an xml
> file in the bootstrap classpath that further loads other configuration.
> Right now, that 'further configuration' is another xml file in the file
> system, but there's no reason that yet further configuration couldn't be
> pulled from a remote configuration service.  So far I'm just solving the
> immediate problem, but trying not to rule out possibilities.
> - pluggable security definition.  It'll be easier to explain when I'm
> just a little further on in the implementation.
> - It's actually built on a dependency-injection framework that is sort
> of a minimalist version of Spring or Google Guice.  In retrospect I
> probably could have used an existing framework, but was having a good
> time learning about annotations.

Are you using the jsr 330 API annotations?  Recent versions of Guice and spring support it, it's a very minimal api.

>
> I haven't looked at "Jini in a jar".

Well worth a look, it allows a user to run a Jini application simply by downloading and running a jar file, it contains the platform, configuration and security config including a key server and has a sysres url scheme to locate resources.

Tim donated it to River last year.

Cheers,

Peter.

>
> I'm pretty close to being able to host "ServiceStarter" services inside
> the container, such that the container hosts its own infrastructure
> (reggie, mahalo, outrigger, etc).  Next step will be to make the
> security infrastructure work, then setup monitoring of a deployment
> directory such that applications can be dynamically deployed/undeployed
> (a-la Tomcat or JBoss) by copying them into the deployment directory.
>
> I'll keep you posted...
>
> Greg.
>
>


--=-OuIjvV8s16A91+TNGv8P--