river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: Split JavaSpaces and JINI
Date Thu, 11 Dec 2008 18:49:44 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;

Perfect!  Easy to have discussion about these items as stated!

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

Is the network use the problem or is there something else about the use of the 
current mechanisms?  Leases don't require any other service to be running, only 
a Landlord impl to use the current mechanisms.  Transactions use mahalo.

Do you know about constructing an com.sun.jini.start.ServiceDescriptor and using 
that in your application to start a network based service in the same process?

com.sun.jini.start.ServiceStarter does this for sets of services provided to it 
in its configuration file, so we could abstract it's behaviors into something 
usable as a library.

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

Do you think that making it possible to get references to a JavaSpace, 
TransactionManager and Landlord instance in a "trivial" way would be a solution, 
or are there other things that would make you really want a "no network" solution?

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

Okay, so we might want to really look at what is going on in Bantam and take 
that community's thoughts and ideas and see if we need to have that in River or 
if it can be a solution external to River?

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

com.sun.jini.start provides this capability.  A PreferredClassLoader is 
seamlessly injected and makes sure that separate services can have completely 
separate codebases, including the platform for anything that is marked as 
preferred in the PREFERRED.LIST.

> 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'm neutral on the Maven issue because I don't have any Maven experience.  I 
know I can build the jars with Ant.  Do we just need a Maven thing on the back 
side that provide the dependency solution for other apps as a starting point, or 
must we really rewire the build to make it work?

> I want to be able to use Jeri without any Jini at all.

There could be a separate jar with just JERI stuff in it.  But I'd still prefer 
there to also be a jsk-platform.jar that is for Jini users.

> 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 guess you can provide some requirements or concepts about what issues these 
classes might deal with.  If you look at http://startnow.dev.java.net and look 
at the class org.wonderly.jini2.PersistentJiniService, you'll see what I use (I 
have not sync'd that site with what I have today, so some bugs etc may still be 
in that code).

public class MyService extends PersistentJiniService {
	public static void main( String args[] ) {
		new MyService( args, null );
	public MyService( String args[], LifeCycle cycle ) {
		super( args );
		... any setup work...

With this style of framework, you can make PersistentJiniService do all kinds of 
stuff based on parameterization from the command line, Configuration entries etc.

With the constructor signature there, it's compatible with com.sun.jini.start.

> 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 think that saying Open Source means simple is Dirt Easy is problematic.  An 
opensource community will refine things that are hard over time, and somethings 
can be simplified.

> I _might_ want to chuck the Configuration system, or at least create
> more familiar alternate implementations.

The Configuration interface is pretty agnostic to underlying expression and 
storage I think.  Having something external create a Map of Maps should make it 
possible to create a ConfigurationMap class that would take 
Map<String,Map<String,Object>> in the constructor and then be able to make the

appropriate accesses.  And certainly this also provides for external dynamic 
updates to configuration which ConfigurationFile requires a new instance to 
allow for.

> Well, that is what I can recall after midnight (now)... Maybe more later...
> Does that help, or am I still confusing?

Makes a world of difference, thanks!

Gregg Wonderly

View raw message