Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Subject: Re: Develop new spec for RMIClassLoader replacement
From: Greg Trasuk <trasukg@stratuscom.com>
To: dev@river.apache.org
In-Reply-To: <58EDBADB-AEE1-4994-814B-4FE03646419B@gmail.com>
References: <5030D778.6030609@zeus.net.au> <50360C90.4000004@qcg.nl>
	 <503627FF.10405@zeus.net.au> <1345746340.2530.220.camel@cameron>
	 <A974ACD2-DA7D-4156-AA65-F6439F0A4BE0@gmail.com>
	 <5039E41E.7050702@zeus.net.au> <1345990661.7614.16.camel@cameron>
	 <C771E0B4-DC5E-4EF1-878E-811EE3C093BE@gmail.com>
	 <0ACC90FF-8981-446A-A072-56F29E68C5E2@gmail.com>
	 <5464567D-F046-485F-B0D0-C5C8072A4217@wonderly.org>
	 <58EDBADB-AEE1-4994-814B-4FE03646419B@gmail.com>
Content-Type: text/plain
Message-Id: <1346039222.7614.30.camel@cameron>
Mime-Version: 1.0
Date: Sun, 26 Aug 2012 23:47:02 -0400
Content-Transfer-Encoding: 7bit


Hi Dennis:

Possibly dumb questions inlined...

Cheers,

Greg.

On Sun, 2012-08-26 at 20:43, Dennis Reedy wrote:
> On Aug 26, 2012, at 723PM, Gregg Wonderly wrote:
> 
> > 
> > On Aug 26, 2012, at 5:12 PM, Dennis Reedy <dennis.reedy@gmail.com>
> wrote:
> > 
> >> Gregg,
> >> 
> >> If you want to use Netbeans RCP, then why not consider making
> everything OSGi-able? We are using a Netbeans RCP front end on a
> project I'm working on now (with a Rio-backend that uses a custom
> RMIClassLoaderSpi that does artifact resolution for an artifact URL,
> goodbye http codebases and good riddance:) ), and from what I see, you
> either need to wrap everything up and turn it into an OSGi module, or
> go whole-hog and make everything OSGi (its all or nothing). 
> > 
> > Hi Dennis!  
> 
> Hi Gregg :)
> 
> > What I'd like to not have to do, is all kinds of packaging and
> versioning control work.  I'd like to be able to just "run watcha
> brung".  Versioning happens, and I can appreciate dealing with it. 
> However, I think it's also a good point of abuse which can lead to
> stuff just not working well, because versioning leads to breakage when
> testing escalates by orders of magnitude and some tests stop getting
> run.  That's what I don't like about the world of OSGi. It seems too
> ridged and too tool intensive for the small applications.
> 
> I agree with your issues wrt OSGi, the only reason I brought it up was
> that NB RCP module system is OSGi based. I'm working with one of the
> NB dream team guys, I think he's on this list, if not maybe I can get
> him to comment and advise. 
> 
> > 
> > I would like to have something that enables all the dynamic code
> flexibility, but which has a much better depends-on graph resolution
> strategy so that one could build all the various "code source" bits
> and fully believe that there wasn't missing classes.
> 
> I'm not sure if this helps (or is of interest to) you, but what I've
> been doing wrt to codebase support is to use the dependency resolution
> that you find with maven based artifacts (note you dont have to have a
> maven project, you just deploy your jars to a maven repository). We've
> been finding it much easier to configure services in a versioned and
> easy-to-deploy way. 
> 
> So what you end up with is the runtime dependencies of a particular
> artifact resolved (direct and transitive dependencies) as the codebase
> for a service, or a service-ui.  So your 'depends on graph' is
> complete, in as much as your dependency graph is correctly constructed
> for your artifact. This comes naturally for maven/gradle projects, you
> can't produce your artifact unless the dependencies have been declared
> correctly.
> 
> Note that this becomes important especially for a client that uses a
> service. With the artifact URL scheme, instead of annotating a
> service's codebase with http:// based jars, the service's codebase
> contains the artifact URL, which (when resolved) resolves the
> dependencies for the service's codebase at the client. This not only
> presents a performance boost (why load classes over http if they can
> be loaded locally), but also addresses lost codebase issues. 

So, the artifact url sticks with the classloader?  Or is it that the
service's artifact url implies a set of jars that will be resolved for
anyone else as well?


> Add to that secure repository connections that require uid/password,
> and you can confirm that the artifact a service requires you download
> in order for you to use that service, comes from a site you trust.
> 

Does everyone in the Djinn need to agree on where the Maven
repository(s) is(are)?  The thing I like about the codebase annotation
is that the service provider can go ahead and setup a web server and the
client finds out everything it needs to know from the annotation.  Can
the clients find the repository configurations dynamically?  Plus, I
suppose you actually have to have a repository setup somewhere, or can a
service container host its own repository?  These may be stupid
questions - I haven't used Maven very much.

> Of course this is all versioned, and once loaded over the wire never
> needs to be loaded again. If the service's version changes, it's
> artifact changes, and any jars that have not been resolved get
> resolved.
> 
> So the dynamic proxy capabilities remain, no change there. 
> 
> Just one more thing. One of my primary motivations for even looking
> into this was to address permanent heap OOME. I found a main
> contributor here was the RMIClassLoader that would keep class loader
> references around because of an HTTP keep alive thread. Addressing
> that issue lead me to this idea of using the artifact URL scheme, and
> avoiding the http URL altogether.
> 
> HTH
> 
> Regards
> 
> Dennis
>