river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: river.jar
Date Mon, 03 Jan 2011 12:21:50 GMT

On Jan 3, 2011, at 1204AM, MICHAEL MCGRADY wrote:

> 
> On Jan 2, 2011, at 7:49 PM, Dennis Reedy wrote:
> 
>> I'm sure I'm missing something, but I'm not sure what a modular build has to do with
classloading at this point.
> 
> 
> If a jar file is in the local class path and includes an implementation, the implementation
it includes is frozen until the VM is rebooted. I take it this is the issue.

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. 





Mime
View raw message