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. Cheers, Greg. > Regards, > > Peter. > > On 27/05/2013 6:28 PM, Greg Trasuk wrote: > > Hi all: > > > > As you know, I've been working for some time on a container for Jini > > services. This work started out as a Surrogate container, but has > > migrated to be a generic container that has similar goals to the old > > Harvester project on jini.org. To wit: > > > > - Provide a simplified deployment environment (simpler than the > > com.sun.jini.Start mechanism) > > - Host multiple services in one VM. e.g. reggie plus business > > services. > > - Handle the task of serving codebase jars without asking much of the > > developer > > - Handle the classpath without asking much of the developer. > > - Provide a platform on which to develop better deployment standards > > - Provide an implementation of the Surrogate spec. > > - Allow for service containers on one machine, by auto-allocating > > codebase ports > > > > The work has been contained up to now in the jtsk/skunk/surrogate > > branch. It has reached a point of relative feature-completeness where > > I'm now comfortable inviting review and participation from other River > > developers. > > > > In light of recent discussions about git I thought I'd try it out, so > > I've moved the bulk of the project into a git repository at > > git://github.com/trasukg/river-container. Eventually of course, the > > nascent Apache git server will hold the canonical copy. > > > > At the same time I'm migrating to Maven. Here's where I need the > > services of someone a little more experienced with Maven than I am. > > Could someone tell me if I'm on the right or wrong track? > > > > I've setup a multi-module project like so: > > > > river-container - parent project > > --river-container-core - Java and associated source for the core > > container > > > > The core jar files need to get assembled with configuration files and > > dependent jars into a deployment layout similar to JBoss or Tomcat. > > Services get assembled and packaged into a jar file somewhat like a web > > application. For integration testing, I need to assemble a test > > container including reggie and the core container components, and so on. > > > > So I'm thinking that I'll add the following modules to the multi-module > > project: > > > > -- reggie-module.ssar - Starter Service Archive module for reggie > > -- river-container-test - container configured with Reggie for testing > > -- river-container-default - container configured for basic use. > > > > Does that make sense? Should the Maven group id be "org.apache.river" > > or "org.apache.river.container"? > > > > Feel free to have a look and let me know. > > > > Greg. > > > >
