This sounds like an opportunity to backport or include the Commission
interface, a service implements this to allow it to be commissioned after
construction.
Commissioning includes starting threads and exporting.
The design intent is to overcome the present limitation where service starting
violates the Java memory model by exposing the service object to other threads
before construction is complete.
Regards,
Peter.
----- Original message -----
>
> On Nov 28, 2013, at 244PM, Greg Trasuk <tras...@stratuscom.com> wrote:
>
> >
> > On Nov 28, 2013, at 12:59 PM, Dennis Reedy <dennis.re...@gmail.com>
> > wrote:
> >
> > >
> > > On Nov 28, 2013, at 1159AM, Greg Trasuk <tras...@stratuscom.com>
> > > wrote:
> > >
> > > >
> > > > I’m all for bringing Rio in at the same time! It’s good to have
> > > > choices.
> > >
> > > Perhaps what we should also focus on is to create (or move forward)
> > > either a standard archive (the SAR) or interfaces that define
> > > semantics for deployment. That way we can have multiple
> > >
> >
> > Probably a good idea. The way the river-container (probably needs a
> > new name) is architected, we can add additional deployers that use
> > alternate semantics or archive formats. The first one I did handles
> > services that are designed for ‘com.sun.jini.start’, but there’s no
> > reason we couldn’t add others. I’m already thinking about
> > re-implementing the Harvester-style API. But even that’s looking
> > pretty dated. That’s what I mean when I say it’ll make a nice test
> > bed - for example, I’d really like to be able to do
> >
> > @Service
> > @ServiceAttributes( { @Name(“Hello”) })
> > public class HelloImpl implements Hello {
> > public String sayHi(String name) {
> > return “Hi there “ + name;
> > }
> > }
> >
>
>
> FWIW, my experience wrt annotations is while they are great for
> lifecycle type things, attributes and other deploy-time things are best
> left in mutable formats.
>
> Looking at supporting a subset of CDI (javax.annotation.PostConstruct,
> javax.annotation.PreDestroy), and adding River service semantics (that
> deal with dynamic service issues; things like PreAdvertise and
> PostUnAdvertise) might be a good start with establishing a base set of
> lifecycle semantics. Keeping configuration items customizable at runtime
> is preferable.
>
>
> What I would like developers to be able to do is create a River service
> using either a multi-module Maven project, an Ant project, or a Gradle
> project, and choose to deploy the service using a choice of River
> service instantiation providers.
>
> We also must have an integrated test-suite that can start River services
> needed to run integration tests. We also need to be able to instantiate
> a service and test it as a River service, but in a unit test scenario.
> For the latter I wrote this, the former uses a JUnit compatible approach
> (easily integrated with Maven failsafe plugin).
>
> I didn't see this in the surrogate project you have (btw do we even need
> to have the surrogate idea any more? Most of the devices in our world
> today host JVMs). This is key IMO.
>
> >
>
> > I see it’s Apache licensed. Ideally we’d have a CCLA in place from
> > all the corporate contributors,
>
> The only two at issue are Sun and GigaSpaces (I am the other 2 :) )
>
> > but I personally don’t know if that’s required if the contributed code
> > is ASL2. We might have to consult more experienced Apache people.
>
> Anyone on the list care to assist here?
>
> Thanks
>
> Dennis
