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 <ge...@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
