incubator-river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman" <>
Subject Re: Split JavaSpaces and JINI
Date Thu, 11 Dec 2008 17:02:41 GMT
On Fri, Dec 12, 2008 at 12:30 AM, Gregg Wonderly <> 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.

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

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.

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".

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.

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

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?


View raw message