Heads-up - Trying out Maven and git for the container.

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

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.

Re: Dynamic Behavior wrt IOC in services.

[Dennis Reedy <de...@gmail.com>]

On May 27, 2013, at 204PM, Greg Trasuk wrote:

> (New subject for an interesting point)
> 
> Good point, Dennis...
> 
> On Mon, 2013-05-27 at 13:30, Dennis Reedy wrote:
>> On May 27, 2013, at 103PM, Greg Trasuk wrote:
>> 
> 
>> Sure, no problem. One big thing to consider wrt container IoC, is that
>> the lifecycle of a River service is different then an EJB. With River,
>> a service can join and leave the network (advertised and
>> unadvertised). Making sure that you consider that has been important
>> in my experience. This when tied with how a service deals with other
>> services (what I call associations
>> http://www.rio-project.org/associations.html), can change the
>> lifecycle of a service. So food for thought
>> 
> 
> I think you're on the right track in Rio, with injecting a dynamic proxy
> for associations.  Curiously, this approach is similar to the dynamic
> proxies injected under JEE6 CDI for contextual objects.

An important distinction perhaps is the service selection strategy that is coupled with the dynamic proxy produced for an associated service declaration. The service selection strategy provides a way to determine how services in the collection of discovered services are invoked. Perhaps a strategy (or chained strategies) could be produced to implement behaviors outlined below.

> 
> Truth is, I've always been hesitant about injecting service
> dependencies, because it seems to me that resolving the services needs
> to be a part of the logic of the service invocation, so that various
> failures can be handled appropriately.
> 
> Couple of scenarios:
> 
> Context - We're talking about a service that depends on one or more
> other services.  When you call service A's 'doSomething()' method, it
> needs to call methods on services B, C, etc.
> 
> Scenario 1- You have a (not very efficient!) policy of looking up every
> service dependency every time A.doSomething() is called.  In this case
> it might just be reasonable to throw an exception (ServiceNotAvailable
> or something similar) and let the client deal with it.  Straight
> injection works in that case.  Or you might want to save the data
> locally and do some alternate handling.  In that case, perhaps it might
> be best to leave the unresolved service references null, so the
> A.doSomething() code can handle it.
> 
> Scenario 2- You have some service references cached.  When you go to do
> A.doSomething(), you find that service B has failed (of course, you find
> this out by means of an IOException when calling service B).  What to
> do?  In the past, I've handled this by dumping all the caches and
> rediscovering the services.  Which means that A.doSomething() has to
> take some control of the dependency resolution, which doesn't fit with
> dependency injection very well.  In Harvester, I had a resolver object
> (I could be wrong, but I think I saw something similar in Rio), so
> A.doSomething() would execute the resolution before attempting to use
> service dependencies.  Then in case of failure, it could call fail() on
> the resolver, which would dump the caches, and attempt resolution again,
> then complete the calls.
> 
> Another issue I've been pondering is how Jini interacts with dynamic IP
> address assignments (i.e. network cards on DHCP).  If the IP address of
> a node changes, it's kind of catastrophic, since the IP addresses of any
> services it exports are probably baked in to both the serialized
> endpoints,

Yes, this could be an issue, but I wonder how probable this is? I had always thought it would be nice to make the network 'observable' so that if the interface changed you could unadvertise, unexport, export then advertise. 


> and the codebase urls (assuming that we pessimistically
> assumed that name-based resolution won't work - arguably the truth in
> most networks).  It seems like in that case, the services' states need
> to roll back to before the endpoints were exported, then re-export and
> re-publish to the registrar.
> 
>> From a client point of view, a client would simply see that as a set of
> services failing, and then go and rediscover the services.  That's no
> problem.  But I wonder how to handle that on the service side.  It's
> almost easiest to just shutdown the services and restart.

Yep. 

> 
> And what happens if a host has more than one IP address (multi-homed)? 

Yeah, multi-homed machines are always fun:) I generally key off the java.rmi.server.hostname system property to use when creating exporters (or other utilities tied to the network).  If not found, I get the first non-loopback address. 

> Again, the services codebases will likely have the IP address baked-in. 
> So a client on one interface needs to use the serialized proxy that
> corresponds to the correct interface.  Here's a case where using Maven
> artifact ids could help handle the codebase issue.  

Indeed it would. You get rid of the lost codebase issue, and also add in performance gains by loading classes locally instead of loading over http (and you load them every time). This is a fundamental problem with the way we have traditionally set up RMI based systems. We can still have the dynamic classloading, but I never create a ClassLoader that loads classes remotely any more. Thats just crazy :)

Dennis

Re: Dynamic Behavior wrt IOC in services.

[Gregg Wonderly <gr...@gmail.com>]

On May 27, 2013, at 6:45 PM, Peter <ji...@zeus.net.au> wrote:

> See inline.
> 
> Cheers,
> 
> Peter.
> ----- Original message -----
>> 
>> 
>> Further discussion below...
>> 
>> Cheers,
>> 
>> Greg.
>> 
>> On Mon, 2013-05-27 at 16:08, Peter wrote:
>>> Now's a great time to standardise a common subset we can all use, this
>>> is a good conversation.
>>> 
>>> We're all solving similar issues, we could have something really great
>>> if we can work together.
>>> 
>>> I created com.sun.jini.start.Starter out of necessity to fix unsafe
>>> publication, however this could take another form.
>>> 
>> Although I've never liked the "export and publish in the costructor"
>> model, I really think the likelihood of having another thread hit the
>> exported object before the constructor is finished is pretty slim. 
> 
> Don't let 'this' escape during construction.
> 
> It's Russian roulette, it's caused test failures for me that have taken me weeks to solve and only then by hand auditing code, I wouldn't want a critical failure to occur in production caused by this escaping during construction, because of the low frequency of failure it's really a very nasty bug.
> 
> So if you have code that exports during construction, fix it now, before it manifests in production.

The single, vital issue, is that we are not talking about only "visibility".  We are also talking about weakly synchronized access.  Non-volatile values which are not protected with synchronized access, can result in "optimizations" reordering operations of the VM in such a way as to expose uninitialized data into threads created to do the work of "join".  Many operating systems will switch to the newly created thread.  It can then see something completely unexpected in the state of the object as it performs marshaling for export etc.

Gregg Wonderly

Re: Dynamic Behavior wrt IOC in services.

[Peter <ji...@zeus.net.au>]

----- Original message -----
> On 5/27/2013 4:45 PM, Peter wrote:
> ...
> > For example the last test failure on arm was caused by it. I couldn't
> > reproduce it on other architectures, but arm had a high frequency of
> > failure.
> ...
>
> Could this be related to ARM's relaxed memory model which reorders some
> memory accesses?
>
> Patricia

That's a probable explanation.  Perhaps we should be testing on Power and Itanium too, these architectures also have relaxed memory models and are inexpensive on ebay.

Re: Dynamic Behavior wrt IOC in services.

[Patricia Shanahan <pa...@acm.org>]

On 5/27/2013 4:45 PM, Peter wrote:
...
> For example the last test failure on arm was caused by it. I couldn't
> reproduce it on other architectures, but arm had a high frequency of
> failure.
...

Could this be related to ARM's relaxed memory model which reorders some
memory accesses?

Patricia

Re: Dynamic Behavior wrt IOC in services.

[Peter <ji...@zeus.net.au>]

See inline.

Cheers,

Peter.
----- Original message -----
>
>
> Further discussion below...
>
> Cheers,
>
> Greg.
>
> On Mon, 2013-05-27 at 16:08, Peter wrote:
> > Now's a great time to standardise a common subset we can all use, this
> > is a good conversation.
> >
> > We're all solving similar issues, we could have something really great
> > if we can work together.
> >
> > I created com.sun.jini.start.Starter out of necessity to fix unsafe
> > publication, however this could take another form.
> >
> Although I've never liked the "export and publish in the costructor"
> model, I really think the likelihood of having another thread hit the
> exported object before the constructor is finished is pretty slim. 

Don't let 'this' escape during construction.

It's Russian roulette, it's caused test failures for me that have taken me weeks to solve and only then by hand auditing code, I wouldn't want a critical failure to occur in production caused by this escaping during construction, because of the low frequency of failure it's really a very nasty bug.

So if you have code that exports during construction, fix it now, before it manifests in production.

For example the last test failure on arm was caused by it. I couldn't reproduce it on other architectures, but arm had a high frequency of failure.

Exporting during construction can break synchronization, don't ask my why, it just did that's all.  Besides Josh Bloch and Doug Lee tell us not to allow this to escape during construction. Who am I to argue with them?

Older jvm's are kinder, but now concurrency and scalability is the priority, these bugs are more likely to occur.

Sim put it succinctly recently, it's akin to when garbage collection became more agressive and objects were collected early breaking existing code.  The same thing is occurring now with concurrency.

Heed the warning, don't let me say "told you so" in a year or two.

There's a real urgency to get it fixed asap.  The fix is simple; export after construction.

> the real use case, the proxy would have to go through a number of
> network calls first before it was accessed by another thread.  Things
> might be different in the test environment, but that can be addressed in
> the test.    As I understand it, you could just synchronize on the proxy,
> and release it before you access it in a subsequent test.
>
> > I've fixed the dynamic IP adressing issue in qa-refactor, see inline
> > further below.
> >
>
> I think we might be talking about different things here.  I'm wondering
> how a running container can deal with a network interface having its IP
> address changed, as when its DHCP lease expires, or when a laptop
> attaches to a different network.

Oh ok, so the codebase issue is only part of the problem, right, detect the change and re-export.


>
> > Also, it might be worth investigating
> > org.apache.river.api.io.Distributed, this allows a non Serializable
> > object to be stored in MarshalledInstance and created on demand, using
> > any constructor, static factory method or builder object.  This object
> > is created in an unpriviliged context, otherwise an attacker could
> > create a Classloader etc.
> >
> > It's so simple, yet so powerful, it's scary.
> >
> I don't quite understand the use case for this.  In the context of a
> client that wants to look up a service in a registrar and then begin to
> use it, without knowing anything about the implementation class, how
> does "org.apache.river.api.io.Distributed" fit into things?

It's orthogonal to the client, to the client it's just another object, however it can be truely immutable with all invarients checked and all fields final so it can be shared without synchronization.

Another case is refactoring code, the developer decides to substitute it with a different class, this would cause an Exception with serialization, the developer can substitute it with another object if it's constructed with a builder.  Distributed objects in marshalled form only contain instructions and parameters for creating an object using reflection during unmarshalling; using a constructor, a static factory method or a builder object.  There is no serial form and the developer is free to change those instructions.

Distributed is akin to distributed injection, the client is not aware of how the object is constructed so it's implementation can remain invisible to the client.  This allows a compact public api to use many different implementations, while the client sees only one type.  It's free from serial form, unfortunately it can't be used as an Entry.

It makes sense to use it to address persistence and concurrency concerns, or as parameters or return values for service methods.

>
> > It's up to the implementor to do something in a privileged context,
> > including getting a login context.
> >
> > Because a Distributed object doesn't need to implement Serializable
> > and because it can be recreated on demand just by calling
> > MarshalledInstance.get(), it allows an implementation to avoid having
> > a serial form, the implementation is then free to change, even to a
> > completely different class.  At present it's intended to be immutable,
> > but that could be relaxed to include a thread safe service.
> >
> > This would allow any service to have it and it's current persisted
> > state stored in a MarshalledInstance for fail over replication to
> > other nodes, to be restored simply by calling get().    Upgrades could
> > be performed simply by persisting and restarting.
> >
> > More inline below.
> > ----- Original message -----
> > > (New subject for an interesting point)
> > >
> > > Good point, Dennis...
> > >
> > > On Mon, 2013-05-27 at 13:30, Dennis Reedy wrote:
> > > > On May 27, 2013, at 103PM, Greg Trasuk wrote:
> > > >
> > >
> > > > Sure, no problem. One big thing to consider wrt container IoC, is
> > that
> > > > the lifecycle of a River service is different then an EJB. With
> > River,
> > > > a service can join and leave the network (advertised and
> > > > unadvertised). Making sure that you consider that has been
> > important
> > > > in my experience. This when tied with how a service deals with
> > other
> > > > services (what I call associations
> > > > http://www.rio-project.org/associations.html), can change the
> > > > lifecycle of a service. So food for thought
> > > >
> > >
> > > I think you're on the right track in Rio, with injecting a dynamic
> > proxy
> > > for associations.  Curiously, this approach is similar to the
> > dynamic
> > > proxies injected under JEE6 CDI for contextual objects.
> > >
> > > Truth is, I've always been hesitant about injecting service
> > > dependencies, because it seems to me that resolving the services
> > needs
> > > to be a part of the logic of the service invocation, so that various
> > > failures can be handled appropriately.
> > >
> > > Couple of scenarios:
> > >
> > > Context - We're talking about a service that depends on one or more
> > > other services.  When you call service A's 'doSomething()' method,
> > it
> > > needs to call methods on services B, C, etc.
> > >
> > > Scenario 1- You have a (not very efficient!) policy of looking up
> > every
> > > service dependency every time A.doSomething() is called.  In this
> > case
> > > it might just be reasonable to throw an exception
> > (ServiceNotAvailable
> > > or something similar) and let the client deal with it.  Straight
> > > injection works in that case.  Or you might want to save the data
> > > locally and do some alternate handling.  In that case, perhaps it
> > might
> > > be best to leave the unresolved service references null, so the
> > > A.doSomething() code can handle it.
> > >
> > > Scenario 2- You have some service references cached.  When you go to
> > do
> > > A.doSomething(), you find that service B has failed (of course, you
> > find
> > > this out by means of an IOException when calling service B).  What
> > to
> > > do?  In the past, I've handled this by dumping all the caches and
> > > rediscovering the services.  Which means that A.doSomething() has to
> > > take some control of the dependency resolution, which doesn't fit
> > with
> > > dependency injection very well.  In Harvester, I had a resolver
> > object
> > > (I could be wrong, but I think I saw something similar in Rio), so
> > > A.doSomething() would execute the resolution before attempting to
> > use
> > > service dependencies.  Then in case of failure, it could call fail()
> > on
> > > the resolver, which would dump the caches, and attempt resolution
> > again,
> > > then complete the calls.
> > >
> > > Another issue I've been pondering is how Jini interacts with dynamic
> > IP
> > > address assignments (i.e. network cards on DHCP).  If the IP address
> > of
> > > a node changes, it's kind of catastrophic, since the IP addresses of
> > any
> > > services it exports are probably baked in to both the serialized
> > > endpoints, and the codebase urls (assuming that we pessimistically
> > > assumed that name-based resolution won't work - arguably the truth
> > in
> > > most networks).
> >
> > I've gone to great lengths to fix this in qa-refactor, however I've
> > also provided a system property that reverts to the present behaviour:
> >
> > -Dnet.jini.loader.codebaseAnnotation=URL
> >
> >
> >    It seems like in that case, the services' states need
> > > to roll back to before the endpoints were exported, then re-export
> > and
> > > re-publish to the registrar.
> > >
> >
> > > > From a client point of view, a client would simply see that as a
> > set of
> > > services failing, and then go and rediscover the services.  That's
> > no
> > > problem.  But I wonder how to handle that on the service side.  It's
> > > almost easiest to just shutdown the services and restart.
> > >
> > > And what happens if a host has more than one IP address
> > (multi-homed)?
> > > Again, the services codebases will likely have the IP address
> > baked-in.
> > > So a client on one interface needs to use the serialized proxy that
> > > corresponds to the correct interface.  Here's a case where using
> > Maven
> > > artifact ids could help handle the codebase issue.  I suspect the
> > > multiple IP addresses could be handled at the JERI level.
> > >
> > > Anyway, lots of things to think about.
> > >
> > > Greg.
> > >
> > > > Regards
> > > >
> > > > Dennis
> > > >
> > > >
> > >
> >
>

Re: Dynamic Behavior wrt IOC in services.

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

Further discussion below...

Cheers,

Greg.

On Mon, 2013-05-27 at 16:08, Peter wrote:
> Now's a great time to standardise a common subset we can all use, this
> is a good conversation.
> 
> We're all solving similar issues, we could have something really great
> if we can work together.
> 
> I created com.sun.jini.start.Starter out of necessity to fix unsafe
> publication, however this could take another form.
> 
Although I've never liked the "export and publish in the costructor"
model, I really think the likelihood of having another thread hit the
exported object before the constructor is finished is pretty slim.  In
the real use case, the proxy would have to go through a number of
network calls first before it was accessed by another thread.  Things
might be different in the test environment, but that can be addressed in
the test.   As I understand it, you could just synchronize on the proxy,
and release it before you access it in a subsequent test.

> I've fixed the dynamic IP adressing issue in qa-refactor, see inline
> further below.
> 

I think we might be talking about different things here.  I'm wondering
how a running container can deal with a network interface having its IP
address changed, as when its DHCP lease expires, or when a laptop
attaches to a different network.

> Also, it might be worth investigating
> org.apache.river.api.io.Distributed, this allows a non Serializable
> object to be stored in MarshalledInstance and created on demand, using
> any constructor, static factory method or builder object.  This object
> is created in an unpriviliged context, otherwise an attacker could
> create a Classloader etc.
> 
> It's so simple, yet so powerful, it's scary.
> 
I don't quite understand the use case for this.  In the context of a
client that wants to look up a service in a registrar and then begin to
use it, without knowing anything about the implementation class, how
does "org.apache.river.api.io.Distributed" fit into things?

> It's up to the implementor to do something in a privileged context,
> including getting a login context.
> 
> Because a Distributed object doesn't need to implement Serializable
> and because it can be recreated on demand just by calling
> MarshalledInstance.get(), it allows an implementation to avoid having
> a serial form, the implementation is then free to change, even to a
> completely different class.  At present it's intended to be immutable,
> but that could be relaxed to include a thread safe service.
> 
> This would allow any service to have it and it's current persisted
> state stored in a MarshalledInstance for fail over replication to
> other nodes, to be restored simply by calling get().   Upgrades could
> be performed simply by persisting and restarting.
> 
> More inline below.
> ----- Original message -----
> > (New subject for an interesting point)
> >
> > Good point, Dennis...
> >
> > On Mon, 2013-05-27 at 13:30, Dennis Reedy wrote:
> > > On May 27, 2013, at 103PM, Greg Trasuk wrote:
> > >
> >
> > > Sure, no problem. One big thing to consider wrt container IoC, is
> that
> > > the lifecycle of a River service is different then an EJB. With
> River,
> > > a service can join and leave the network (advertised and
> > > unadvertised). Making sure that you consider that has been
> important
> > > in my experience. This when tied with how a service deals with
> other
> > > services (what I call associations
> > > http://www.rio-project.org/associations.html), can change the
> > > lifecycle of a service. So food for thought
> > >
> >
> > I think you're on the right track in Rio, with injecting a dynamic
> proxy
> > for associations.  Curiously, this approach is similar to the
> dynamic
> > proxies injected under JEE6 CDI for contextual objects.
> >
> > Truth is, I've always been hesitant about injecting service
> > dependencies, because it seems to me that resolving the services
> needs
> > to be a part of the logic of the service invocation, so that various
> > failures can be handled appropriately.
> >
> > Couple of scenarios:
> >
> > Context - We're talking about a service that depends on one or more
> > other services.  When you call service A's 'doSomething()' method,
> it
> > needs to call methods on services B, C, etc.
> >
> > Scenario 1- You have a (not very efficient!) policy of looking up
> every
> > service dependency every time A.doSomething() is called.  In this
> case
> > it might just be reasonable to throw an exception
> (ServiceNotAvailable
> > or something similar) and let the client deal with it.  Straight
> > injection works in that case.  Or you might want to save the data
> > locally and do some alternate handling.  In that case, perhaps it
> might
> > be best to leave the unresolved service references null, so the
> > A.doSomething() code can handle it.
> >
> > Scenario 2- You have some service references cached.  When you go to
> do
> > A.doSomething(), you find that service B has failed (of course, you
> find
> > this out by means of an IOException when calling service B).  What
> to
> > do?  In the past, I've handled this by dumping all the caches and
> > rediscovering the services.  Which means that A.doSomething() has to
> > take some control of the dependency resolution, which doesn't fit
> with
> > dependency injection very well.  In Harvester, I had a resolver
> object
> > (I could be wrong, but I think I saw something similar in Rio), so
> > A.doSomething() would execute the resolution before attempting to
> use
> > service dependencies.  Then in case of failure, it could call fail()
> on
> > the resolver, which would dump the caches, and attempt resolution
> again,
> > then complete the calls.
> >
> > Another issue I've been pondering is how Jini interacts with dynamic
> IP
> > address assignments (i.e. network cards on DHCP).  If the IP address
> of
> > a node changes, it's kind of catastrophic, since the IP addresses of
> any
> > services it exports are probably baked in to both the serialized
> > endpoints, and the codebase urls (assuming that we pessimistically
> > assumed that name-based resolution won't work - arguably the truth
> in
> > most networks).
> 
> I've gone to great lengths to fix this in qa-refactor, however I've
> also provided a system property that reverts to the present behaviour:
> 
> -Dnet.jini.loader.codebaseAnnotation=URL
> 
> 
>   It seems like in that case, the services' states need
> > to roll back to before the endpoints were exported, then re-export
> and
> > re-publish to the registrar.
> >
> 
> > > From a client point of view, a client would simply see that as a
> set of
> > services failing, and then go and rediscover the services.  That's
> no
> > problem.  But I wonder how to handle that on the service side.  It's
> > almost easiest to just shutdown the services and restart.
> >
> > And what happens if a host has more than one IP address
> (multi-homed)?
> > Again, the services codebases will likely have the IP address
> baked-in.
> > So a client on one interface needs to use the serialized proxy that
> > corresponds to the correct interface.  Here's a case where using
> Maven
> > artifact ids could help handle the codebase issue.  I suspect the
> > multiple IP addresses could be handled at the JERI level.
> >
> > Anyway, lots of things to think about.
> >
> > Greg.
> >
> > > Regards
> > >
> > > Dennis
> > >
> > >
> >
> 

Re: Dynamic Behavior wrt IOC in services.

[Peter <ji...@zeus.net.au>]

Now's a great time to standardise a common subset we can all use, this is a good conversation.

We're all solving similar issues, we could have something really great if we can work together.

I created com.sun.jini.start.Starter out of necessity to fix unsafe publication, however this could take another form.

I've fixed the dynamic IP adressing issue in qa-refactor, see inline further below.

Also, it might be worth investigating org.apache.river.api.io.Distributed, this allows a non Serializable object to be stored in MarshalledInstance and created on demand, using any constructor, static factory method or builder object.  This object is created in an unpriviliged context, otherwise an attacker could create a Classloader etc.

It's so simple, yet so powerful, it's scary.

It's up to the implementor to do something in a privileged context, including getting a login context.

Because a Distributed object doesn't need to implement Serializable and because it can be recreated on demand just by calling MarshalledInstance.get(), it allows an implementation to avoid having a serial form, the implementation is then free to change, even to a completely different class.  At present it's intended to be immutable, but that could be relaxed to include a thread safe service.

This would allow any service to have it and it's current persisted state stored in a MarshalledInstance for fail over replication to other nodes, to be restored simply by calling get().   Upgrades could be performed simply by persisting and restarting.

More inline below.
----- Original message -----
> (New subject for an interesting point)
>
> Good point, Dennis...
>
> On Mon, 2013-05-27 at 13:30, Dennis Reedy wrote:
> > On May 27, 2013, at 103PM, Greg Trasuk wrote:
> >
>
> > Sure, no problem. One big thing to consider wrt container IoC, is that
> > the lifecycle of a River service is different then an EJB. With River,
> > a service can join and leave the network (advertised and
> > unadvertised). Making sure that you consider that has been important
> > in my experience. This when tied with how a service deals with other
> > services (what I call associations
> > http://www.rio-project.org/associations.html), can change the
> > lifecycle of a service. So food for thought
> >
>
> I think you're on the right track in Rio, with injecting a dynamic proxy
> for associations.  Curiously, this approach is similar to the dynamic
> proxies injected under JEE6 CDI for contextual objects.
>
> Truth is, I've always been hesitant about injecting service
> dependencies, because it seems to me that resolving the services needs
> to be a part of the logic of the service invocation, so that various
> failures can be handled appropriately.
>
> Couple of scenarios:
>
> Context - We're talking about a service that depends on one or more
> other services.  When you call service A's 'doSomething()' method, it
> needs to call methods on services B, C, etc.
>
> Scenario 1- You have a (not very efficient!) policy of looking up every
> service dependency every time A.doSomething() is called.  In this case
> it might just be reasonable to throw an exception (ServiceNotAvailable
> or something similar) and let the client deal with it.  Straight
> injection works in that case.  Or you might want to save the data
> locally and do some alternate handling.  In that case, perhaps it might
> be best to leave the unresolved service references null, so the
> A.doSomething() code can handle it.
>
> Scenario 2- You have some service references cached.  When you go to do
> A.doSomething(), you find that service B has failed (of course, you find
> this out by means of an IOException when calling service B).  What to
> do?  In the past, I've handled this by dumping all the caches and
> rediscovering the services.  Which means that A.doSomething() has to
> take some control of the dependency resolution, which doesn't fit with
> dependency injection very well.  In Harvester, I had a resolver object
> (I could be wrong, but I think I saw something similar in Rio), so
> A.doSomething() would execute the resolution before attempting to use
> service dependencies.  Then in case of failure, it could call fail() on
> the resolver, which would dump the caches, and attempt resolution again,
> then complete the calls.
>
> Another issue I've been pondering is how Jini interacts with dynamic IP
> address assignments (i.e. network cards on DHCP).  If the IP address of
> a node changes, it's kind of catastrophic, since the IP addresses of any
> services it exports are probably baked in to both the serialized
> endpoints, and the codebase urls (assuming that we pessimistically
> assumed that name-based resolution won't work - arguably the truth in
> most networks).

I've gone to great lengths to fix this in qa-refactor, however I've also provided a system property that reverts to the present behaviour:

-Dnet.jini.loader.codebaseAnnotation=URL


  It seems like in that case, the services' states need
> to roll back to before the endpoints were exported, then re-export and
> re-publish to the registrar.
>

> > From a client point of view, a client would simply see that as a set of
> services failing, and then go and rediscover the services.  That's no
> problem.  But I wonder how to handle that on the service side.  It's
> almost easiest to just shutdown the services and restart.
>
> And what happens if a host has more than one IP address (multi-homed)?
> Again, the services codebases will likely have the IP address baked-in.
> So a client on one interface needs to use the serialized proxy that
> corresponds to the correct interface.  Here's a case where using Maven
> artifact ids could help handle the codebase issue.  I suspect the
> multiple IP addresses could be handled at the JERI level.
>
> Anyway, lots of things to think about.
>
> Greg.
>
> > Regards
> >
> > Dennis
> >
> >
>

Dynamic Behavior wrt IOC in services.

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

(New subject for an interesting point)

Good point, Dennis...

On Mon, 2013-05-27 at 13:30, Dennis Reedy wrote:
> On May 27, 2013, at 103PM, Greg Trasuk wrote:
> 

> Sure, no problem. One big thing to consider wrt container IoC, is that
> the lifecycle of a River service is different then an EJB. With River,
> a service can join and leave the network (advertised and
> unadvertised). Making sure that you consider that has been important
> in my experience. This when tied with how a service deals with other
> services (what I call associations
> http://www.rio-project.org/associations.html), can change the
> lifecycle of a service. So food for thought
> 

I think you're on the right track in Rio, with injecting a dynamic proxy
for associations.  Curiously, this approach is similar to the dynamic
proxies injected under JEE6 CDI for contextual objects.

Truth is, I've always been hesitant about injecting service
dependencies, because it seems to me that resolving the services needs
to be a part of the logic of the service invocation, so that various
failures can be handled appropriately.

Couple of scenarios:

Context - We're talking about a service that depends on one or more
other services.  When you call service A's 'doSomething()' method, it
needs to call methods on services B, C, etc.

Scenario 1- You have a (not very efficient!) policy of looking up every
service dependency every time A.doSomething() is called.  In this case
it might just be reasonable to throw an exception (ServiceNotAvailable
or something similar) and let the client deal with it.  Straight
injection works in that case.  Or you might want to save the data
locally and do some alternate handling.  In that case, perhaps it might
be best to leave the unresolved service references null, so the
A.doSomething() code can handle it.

Scenario 2- You have some service references cached.  When you go to do
A.doSomething(), you find that service B has failed (of course, you find
this out by means of an IOException when calling service B).  What to
do?  In the past, I've handled this by dumping all the caches and
rediscovering the services.  Which means that A.doSomething() has to
take some control of the dependency resolution, which doesn't fit with
dependency injection very well.  In Harvester, I had a resolver object
(I could be wrong, but I think I saw something similar in Rio), so
A.doSomething() would execute the resolution before attempting to use
service dependencies.  Then in case of failure, it could call fail() on
the resolver, which would dump the caches, and attempt resolution again,
then complete the calls.

Another issue I've been pondering is how Jini interacts with dynamic IP
address assignments (i.e. network cards on DHCP).  If the IP address of
a node changes, it's kind of catastrophic, since the IP addresses of any
services it exports are probably baked in to both the serialized
endpoints, and the codebase urls (assuming that we pessimistically
assumed that name-based resolution won't work - arguably the truth in
most networks).  It seems like in that case, the services' states need
to roll back to before the endpoints were exported, then re-export and
re-publish to the registrar.

>From a client point of view, a client would simply see that as a set of
services failing, and then go and rediscover the services.  That's no
problem.  But I wonder how to handle that on the service side.  It's
almost easiest to just shutdown the services and restart.

And what happens if a host has more than one IP address (multi-homed)? 
Again, the services codebases will likely have the IP address baked-in. 
So a client on one interface needs to use the serialized proxy that
corresponds to the correct interface.  Here's a case where using Maven
artifact ids could help handle the codebase issue.  I suspect the
multiple IP addresses could be handled at the JERI level.

Anyway, lots of things to think about.

Greg.

> Regards
> 
> Dennis
> 
> 

Re: Heads-up - Trying out Maven and git for the container.

[Dennis Reedy <de...@gmail.com>]

On May 27, 2013, at 103PM, Greg Trasuk wrote:

> 
> 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).

Sure, no problem. One big thing to consider wrt container IoC, is that the lifecycle of a River service is different then an EJB. With River, a service can join and leave the network (advertised and unadvertised). Making sure that you consider that has been important in my experience. This when tied with how a service deals with other services (what I call associations http://www.rio-project.org/associations.html), can change the lifecycle of a service. So food for thought

Regards

Dennis

Re: Heads-up - Trying out Maven and git for the container.

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

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

Re: Heads-up - Trying out Maven and git for the container.

[Dennis Reedy <de...@gmail.com>]

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

Re: Heads-up - Trying out Maven and git for the container.

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

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.
> >
> >

Re: Heads-up - Trying out Maven and git for the container.

[Peter Firmstone <ji...@zeus.net.au>]

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?

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.
>
>

Re: Heads-up - Trying out Maven and git for the container.

[Peter <ji...@zeus.net.au>]

Hi Greg,

I noticed while reading your docs, you've got a java policy parser planned, there's a parser in org.apache.river.api.security (package private) that fully supports java policy file syntax, including undocumented features, as well as PermissionGrant, which makes policy implementation simpler, easier to implement and is also non blocking, so policy deadlock can be avoided.

The PolicyParser interface is public, to allow alternate parsers, such as xml, or encrypted policy files.

In future I also plan to implement a parser for OSGi syntax permission.perm in jar files as previously discussed on the list.

Perhaps we might have some common use cases?

Regards,

Peter.

----- Original message -----
> 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.
>
>

Re: Heads-up - Trying out Maven and git for the container.

[Peter Firmstone <ji...@zeus.net.au>]

On 27/05/2013 10:05 PM, Dennis Reedy wrote:
> On May 27, 2013, at 737AM, Peter Firmstone wrote:
>
>> Yes we really should standardise these conventions, Dennis, have you had any thoughts about doing some standards docs?
> No, I really haven't. What would make it standards docs?

A place among the other Jini standards, similar to ServiceUI as a 
community contribution.

The naming and dependency conventions are fundamental concepts that help 
developers understand how various service components are related, so 
it's suitable for other dependency / module systems in addition to Maven.


>> I'd also like to see Rivers deployment jars be updated to follow these conventions.
> I agree.
>
> Dennis
>

Re: Heads-up - Trying out Maven and git for the container.

[Dennis Reedy <de...@gmail.com>]

On May 27, 2013, at 737AM, Peter Firmstone wrote:

> Yes we really should standardise these conventions, Dennis, have you had any thoughts about doing some standards docs?

No, I really haven't. What would make it standards docs?

> 
> I'd also like to see Rivers deployment jars be updated to follow these conventions.

I agree.

Dennis

Re: Heads-up - Trying out Maven and git for the container.

[Peter Firmstone <ji...@zeus.net.au>]

Yes we really should standardise these conventions, Dennis, have you had 
any thoughts about doing some standards docs?

I'd also like to see Rivers deployment jars be updated to follow these 
conventions.

Regards,

Peter.

On 27/05/2013 9:29 PM, Dennis Reedy wrote:
> Greg,
>
> You could take a look at what I've done with Rio and the recommended conventions http://www.rio-project.org/conventions.html. FWIW, most of what you outline below (sans surrogate) is what we've been doing with Rio, you should check it out (or fork it on github :)).
>
> Regards
>
> Dennis
>
> On May 27, 2013, at 428AM, 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.
>>
>>

Re: Heads-up - Trying out Maven and git for the container.

[Dennis Reedy <de...@gmail.com>]

Greg,

You could take a look at what I've done with Rio and the recommended conventions http://www.rio-project.org/conventions.html. FWIW, most of what you outline below (sans surrogate) is what we've been doing with Rio, you should check it out (or fork it on github :)).

Regards

Dennis

On May 27, 2013, at 428AM, 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.
> 
>