Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of kecampbell@mac.com designates
 17.148.16.86 as permitted sender)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Message-id: <26E8E284-D480-4586-B6B0-36B35D0A932C@mac.com>
From: Keith Campbell <kecampbell@mac.com>
To: river-dev@incubator.apache.org
In-reply-to: <caf30e2a0812110902h2d19e62dw13edaaef1fc27faa@mail.gmail.com>
Subject: Re: Split JavaSpaces and JINI
Date: Thu, 11 Dec 2008 09:20:58 -0800
References: <964EAC824495234A86F3C47DA8BD8AAD17750A@sucden-exch.sucden.co.uk>
 <493D40A9.7020808@wizards.de>
 <863EA217-8B6B-4881-867E-8A645A036276@topiatechnology.com>
 <493D77B0.5060803@wonderly.org>
 <caf30e2a0812082235v1259a654r840eabc0c151329d@mail.gmail.com>
 <493E9460.1030901@wonderly.org>
 <caf30e2a0812091807u20b45c02yfd69108259902d12@mail.gmail.com>
 <493FEAA1.7030708@cox.net>
 <caf30e2a0812101858t1fba4351q907c0c5d5a3c4f5d@mail.gmail.com>
 <4941402C.7050405@cox.net>
 <caf30e2a0812110902h2d19e62dw13edaaef1fc27faa@mail.gmail.com>

Well, this description really works for me now. It echos some similar  
issues that I've been forced to face with my own deployments.

I have many circumstances where I want a single JVM deployment (for  
example, for a local application in circumstances where the IP address  
may dynamically change while the application is still running because  
you move from one WiFi network to another, but you are not actually  
using or caring about the network), and have had to do serious abuse  
to the sun provided transaction manger to get it to run within a  
single JVM with no network requirement.

I think having a local JVM transaction manager and discovery manager  
that does not use the network, and can be a default configuration is  
something that I'm very interested in having. This would help with  
mock testing, and also in some deployment situations where a multi- 
threaded application on multiple cores on a stand-alone machine is all  
that is required (no downloadable code necessary). And then to have a  
straight forward upgrade path to moving that application to the  
network with minimal fuss.

I think that the interfaces are less the issue than getting these  
stand-alone non-networked services to use a smart proxy to recognize  
when they are in the same JVM and rely on some type of statically  
accessible discovery manager to get non-networked stubs.

Getting such an environment to run and deploy in maven will also make  
the package simpler to approach, and will make my job working with  
Jini/river easier.

Keith


On Dec 11, 2008, at 9:02 AM, 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.
>
> 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.
>
> 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
> 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?
>
>
> Cheers
> Niclas