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
