Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Subject: Re: river.jar
From: Greg Trasuk <trasukg@stratuscom.com>
To: river-dev@incubator.apache.org
In-Reply-To: <1F6EE127-359C-4926-BD8F-47F8EE3A5A3F@gmail.com>
References: 
	 <868267689-1293812305-cardhu_decombobulator_blackberry.rim.net-1615482016-@bda634.bisx.prod.on.blackberry>
	 <4D203C95.1010404@zeus.net.au>
	 <AANLkTin+OtGa3jc08L98qTkCw1ftoJmX+X5C1vAGmZ9s@mail.gmail.com>
	 <1293986161.3904.13.camel@cameron>
	 <AANLkTinLD_3OF2ph8rYLWqSu+4aoeT8Wyrr44rr4yfda@mail.gmail.com>
	 <4D212CCE.8000303@zeus.net.au> <1294024192.3904.62.camel@cameron>
	 <68F908AC-7478-4E0B-81E4-D70F9EB18A33@gmail.com>
	 <98A4E426-B0F2-429A-B8A4-B083AFF2D776@topiatechnology.com>
	 <1F6EE127-359C-4926-BD8F-47F8EE3A5A3F@gmail.com>
Content-Type: text/plain
Message-Id: <1294069423.3904.106.camel@cameron>
Mime-Version: 1.0
Date: Mon, 03 Jan 2011 10:43:44 -0500
Content-Transfer-Encoding: 7bit


On Mon, 2011-01-03 at 07:21, Dennis Reedy wrote:

> If you look at how the current distribution is used when starting services (via ServiceStarter), you'll see that a bare minimum is included in the VM's classpath. There should never be any service implementation classes (or jars) included in the classpath of the JVM. Each service is currently created with it's own classloader, and that classloader has as it's searchpath the service implementation jar(s). While your concern is noted, I dont believe it really is an issue.
> 
> A great deal of thought has been put into the construction of jars for Jini (River). I dont see a compelling reason to change this. IMO, the goal of a modularized build is not to change the jars, but to create a project structure that allows each of the artifacts to be assembled in a modular fashion. 
> 
> 
> 
> 

I'd just like to echo and support what Dennis said.  The original
question was "should we have a large river.jar that contains all the
River executables?"  I agree with Dennis that a lot of experience and
thinking went into the jar file structure, preferred classloader
architecture and associated class loader hierarchy, and we should not
jump to abandon that learning.

As an aside, we seem to have a side-track into classloading.  I hate to
say it, lest I be accused of being an old fart impeding progress, but I
think here we have a minor disconnect between those of us who have been
using Jini for a while (some of us for 10+ years now!) and people who
are just discovering Jini's magic.  So when someone says "you know,
maybe proxies shouldn't be in the same classloader as client code", some
of us old-timers probably think "well, yeah, that's a given" and try to
tactfully suggest investigating the status-quo a little further (e.g. by
pointing out ServiceStarter or the PreferredClassLoader concept), and
hope the questions go away.

I'm not sure how to handle that, but I suspect that's behind some of the
resistance that you see to changing the jar file structures.  I can only
say that Jini isn't actually cargo-cult programming; mostly it is the
way it is because it works.  Not that there aren't things to be fixed,
as for example, Patricia Shanahan has demonstrated with her Outrigger
work.  Or improvements to be made (I still think, for instance, that
deployment with ServiceStarter is a little too hard-core-coder-oriented
for the mainstream). We just need to approach change with an open mind
and with a good understanding of what we're looking at.

Cheers,

Greg.