river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Jini Activation Framework - A sub project?
Date Mon, 03 May 2010 21:32:34 GMT
Hi Gregg,

I'm thinking about is how to create the next distribution release 
artifacts, namely, creating a platform release artifact that excludes 
Activation.  The Java CDC release artifact (zip archive) will be 
identical apart from lacking any depreciated classes or methods.

I had figured a Mahalo implementation should be included in the Apache 
Release (without Activation), I want to remove the dependency on 
Activation being present in the Classpath.  I'll have to do this for a 
Java CDC release anyway.

Your use of Norm is interesting, I didn't want to include Norm in the 
base release.  It sounds like your using Norm to control the liveliness 
of your exports, it also sound like these proxy's aren't registered with 
the lookup service, tell me more?

My thoughts were:

    * A separate release artifact for the Activation Framework.
    * Platform release artifacts for Java SE and Java CDC.

Your comments are making me think:

    * A separate release artifact for the Activation Framework (phoenix,
      specific to Java SE).
    * Basic platform release artifact (With a very wide platform support
      base, one for Java SE 5+, one for Java CDC 1.11).
    * One or more Service release artifacts, I want Reggie to take
      advantage of the latest java language and concurrency features,
      however I want to be able to install other services without
      requiring the Activation Framework release to also be installed,
      I'm still figuring this bit out.



Gregg Wonderly wrote:
> I use norm and mahalo all the time without activation.  I use a leased smart proxy instead
of DGC so that all of the details of proxy management are under my control and I use transactions
without activation for mahalos lifecycle.
> Gregg wonderly
> Sent from my iPad
> On May 2, 2010, at 8:37 PM, Peter Firmstone <jini@zeus.net.au> wrote:
>> My reasoning for removal from the platform spec or making it optional: Activation
is a Service implementation detail.
>> If there are no objections, I'd like to move it in the near future.
>> Regards,
>> Peter.
>> Peter Firmstone wrote:
>>> Can we move the Activation Framework to a subproject of Apache River?  So it
isn't part of the platform?
>>> The Activation Framework could be optional and include the following:
>>>   * Phoenix - Activation Service
>>>   * Norm - Lease Service (This doesn't make much sense outside Activation)
>>>   * Activatable Fiddler - Lookup Discovery Service
>>>   * Activatable Reggie - Service Registrar
>>>   * Activatable Javaspaces - Outrigger FrontEndSpace.
>>>   * Mahalo - Transaction Service (We can create a Non-Activatable
>>>     implementation for the platform)
>>>   * Mecury - Event mailbox (We can create a Non-Activatable
>>>     implementation for the platform)
>>> These could be bundled together as an Activation Framework Release
>>> Existing interfaces that are specific to Activation in the net.jini namespace
(exclusive of net.jini.activation) could be depreciated and copied to another package namespace,
giving existing applications time to transition.
>>> Then the activation framework becomes something that runs on top of Jini / Apache
River, rather than part of it, making Jini / River conceptually simpler to new application
>>> What are your thoughts?
>>> Regards,
>>> Peter.

View raw message