river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <...@dcrdev.demon.co.uk>
Subject Re: Split JavaSpaces and JINI
Date Sat, 20 Dec 2008 10:51:41 GMT
Niclas Hedhman wrote:
> On Fri, Dec 12, 2008 at 12:30 AM, Gregg Wonderly <gergg@cox.net> wrote:
>> Perhaps Niclas you can enumerate all the reasons why JavaSpace shouldn't
>> have transactions or leases?
>> I'm dead serious about trying to understand what you are saying.
> Ok, let's try this again;
> I want the 'package' that is offered to "me" to have local-JVM
> implementations that are plug-replaceable with distributed ones. I
> don't want to "yank" out Transactions and Leases, I want to be able to
> use them easily locally without network traffic.

Okay, so you don't mind writing code that handles networking conditions
even though they aren't present in a "local" configuration?

If that's the case, I don't think you need to write local-JVM
implementations, I think this is back to base-line configurations,
hiding a bunch of stuff, writing some auto-detection/setup code and
merging in some bits that Bob S wrote a while back to do in-JVM
communication whilst looking like JERI endpoints.

> I want an introduction path into this world going through that
> 'local-JVM' variant first, and slowly introducing the more complex
> aspects of Jini to me. I don't want to know that I have 3-4 transport
> protocols, some with endless options, and I don't want to know the
> details of setting up security (just assume I am the ignorant b'stard
> that I am and give me AllPermissions until I sober up). I don't want
> to see configuration files in a "Java-like" language, either give me a
> straight shooting API, properties files or worst-case a Spring app
> context...
> I want to deploy my first Jini services and clients in a WAR on
> Tomcat, without having to ask my NetAdmin to alter any setup and know
> that it works out of the box everywhere.

This implies a drift from local to remote - now unfortunately you have
incompatible classloader models to face, network config to do etc.  All
those things that are core to Jini that other enterprise setups don't do
 because of their environmental assumptions (limited support for
multiple versions, nothing breaks etc).

So the out of the box stuff I think we can certainly sort, this one I'm
less sure of.  Though things like Bantam get you somewhere near.

> I want services to be under the control of Java code that I write. I
> don't want to ever hear about RMID and Activation ever again. I don't
> want to encounter classloading problems when services are in the same
> JVM, even if they depend on different versions of Jini "Core".

You won't get that wish with the classloader models of many existing
containers.  Sorry for labouring the point.

On RMID and Activation, you don't need those (I rarely use them).  And
you can have programmatic control of services including doing startup
(I've written a container that does it without making any changes to
services or Jini out of the box and does remote deployment in a single
.jar etc).

> I want every bit of the system to be Maven adapted, so that my Maven
> project can consume the meta-data easily. Jini is a toolkit, and not a
> installable application for JC's sake.
> I want to be able to use Jeri without any Jini at all.

Errr you can - it's just a bunch of .jars - you don't need lookup,
transaction managers etc.

Again, I know this because I've done it.

> I want to be able to easily(!) test my Jini clients and services
> within a single JVM (otherwise too hard to automate), preferably via a
> single AbstractJiniServiceTestcase and AbstractJiniClientTestcase
> doing all the bits for me. And of course, those take care of whether I
> am testing against InMemory or OverNetwork versions of the services.
> I want River to 'feel' like an open source and accessible project.
> Simple things should be dirt easy and complex things should be
> possible.
> I _might_ want to chuck the Configuration system, or at least create
> more familiar alternate implementations.
> Well, that is what I can recall after midnight (now)... Maybe more later...
> Does that help, or am I still confusing?

Yes it does help.

> Cheers
> Niclas

View raw message