Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: error (athena.apache.org: local policy)
Subject: Re: Heads-up - Trying out Maven and git for the container.
From: Greg Trasuk <trasukg@stratuscom.com>
To: dev@river.apache.org
In-Reply-To: <FDCC1157-4321-472F-A5AC-01C9A4E8A2D3@gmail.com>
References: <1369643300.9475.263.camel@cameron>
	 <51A355D7.4090804@zeus.net.au> <1369663342.9475.284.camel@cameron>
	 <FDCC1157-4321-472F-A5AC-01C9A4E8A2D3@gmail.com>
Content-Type: text/plain; charset=iso-8859-1
Message-Id: <1369674209.9475.302.camel@cameron>
Mime-Version: 1.0
Date: Mon, 27 May 2013 13:03:30 -0400
Content-Transfer-Encoding: 7bit


Dennis:

I'll take a fresh look at Rio over the coming week or two.  As you know,
I've always held the Rio project in high regard.  When I looked at it
some years ago, I felt it was addressing a number of concerns, like QOS
and mobile code, that I didn't have, and hence it seemed complicated for
what I was trying to do.  But time marches, on, I suppose.

I continue to believe that there's room for a plurality of container
concepts.  Although it would be great if we could set down a standard
for deployment conventions, much like the way JEE does.  I'm of the
opinion that the com.sun.jini.starter convention leaves a little to be
desired.  It pretty much assumes that the service is in control of the
VM, rather than embrace container-style inversion of control (a-la
servlets or EJBs).

Greg.

On Mon, 2013-05-27 at 12:01, Dennis Reedy wrote:
> On May 27, 2013, at 1002AM, Greg Trasuk wrote:
> 
> > 
> > On Mon, 2013-05-27 at 08:47, Peter Firmstone wrote:
> >> Well done Greg, hey I noticed you've got an annotation called Init, this 
> >> would allow a service to be exported and have any threads started after 
> >> construction wouldn't it?
> >> 
> > 
> > Eventually, yes.  Right now, the annotations are part of a stripped-down
> > dependency-injection framework that sets up all the components that form
> > the container itself.  (I did have reasons for not using an
> > off-the-shelf DI framework - see the AnnotatedClassDeployer source code
> > for them).  For the record, yes, initialization is a separate operation
> > from construction.
> > 
> > One of those components is one or more "deployers" that knows how to
> > interpret a given file and startup a service instance.  As it stands,
> > I've written a deployer that executes services that are written to the
> > "com.sun.jini.start" conventions, like Reggie, Outrigger, etc. 
> > Basically this is so that the container can host all the infrastructure
> > services if desired.
> > 
> > Longer-term, I'd like to see a deployer that deploys services written to
> > a more developer-friendly convention (that we will need to develop). 
> > One option for that would be to have a CDI-like framework, where you
> > would simply annotate a class with "@Service" or something similar, and
> > let the deployer take care of all the startup and publication details.
> > 
> > Historically, my goal has been to make creating a Jini service as easy
> > as writing servlets.  Nowadays, I think we have to aim for "as easy as
> > creating EJBs using CDI", which is arguably pretty easy.
> 
> Apologies for sounding like a broken record, but this was (is) a goal of Rio as well. All you need is a POJO (and if you like Spring integration thats available as well). Its really even simpler if you use the Rio Maven archetype, you get a project generated for you, with test code, and deployment configuration (http://www.rio-project.org/tutorial/service/service-intro.html). 
> 
> Would it be of interest to discuss how you may take advantage of whats out there?
> 
> Regards
> 
> Dennis