Comments and questions intertwined…
Greg.
On Nov 28, 2013, at 5:26 PM, Dennis Reedy <dennis.re...@gmail.com> wrote:
>
> 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.
>
Mostly agree. For instance, I don’t think I’d want to specify invocation
constraints in an annotation. On the other hand, some attributes, like Name or
ServiceInfo seem pretty static. I think we’d have to have some way to say
“this is a service” in an annotation, blended with “look in the Configuration
object under name XYZ for the details”. In addition, what I found with
Harvester was that it was very useful to be able to instantiate an object as a
“component” that was available in the application context but wasn’t exported
as a service.
In the container as it stands, the global configuration can be selectively
passed in to the individual services’ configuration as “special” values. For
instance the default discovery group name is available in a configuration file
as $discoveryGroup, but is actually set in the profile’s ‘config.xml’ file.
That way, services deployed into a profile can easily inherit the discovery
group that is set in the profile (although they don’t have to).
> 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.
>
I like CDI and Spring-style DI for building the application’s object graph. I
actually wonder if we could use Apache OpenWebBeans to implement a lot of CDI
functionality, then add in Jini services to it. For instance, would it make
sense to create an InvocationLayer implementation that did dependency injection
and resolved service references before placing the call on the service
implementation? The problem there becomes “what happens when resolution
fails?” In an EJB-based CDI instance, resolution failure indicates an
application bug (you’re missing CDI components). But in a network system,
resolution failure is to be expected if a service is offline, so the
application needs to be involved. It gets much more complicated than EJB,
which is static. I think you’d have to have a @OnResolutionFailure method, and
then somehow allow the call to proceed or fail based on the results of that
method. You could also have a proxy that re-tries the resolution, but again I
think you can’t abstract failure away from the application.
>
> 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.
>
Agreed. Developers need to have a simple way to create and deploy services and
clients. I recall reading Dan Creswell’s “How to write a Jini Service”
(http://www.jroller.com/dancres/entry/how_to_write_a_jini) and thinking it
reads like satire, even though it is completely accurate.
> 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
Let me read that back to make sure I understand. We need to have a test suite
that starts up the River infrastructure services (like Reggie, Mahalo,
Outrigger, etc) in a unique workgroup so that we can test services. And we
need to instantiate Unit-Under-Test services in that environment (probably not
in the same container), and then also execute a JUnit test that can lookup the
actual service and make calls on the proxy, all inside the Maven integration
test framework. Do I have that right?
I have to confess that I don’t yet understand how to do integration testing
under Maven. So any hints are appreciated.
> (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.
Yeah, the surrogate idea is not a very persuasive use case now. Although I can
see one or two applications for it. For instance I could picture a surrogate
popping up an admin interface to a cloud-based virtual machine image, so you
could use the surrogate to start up processes or deploy software on the VM.
>>
>
>> 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
