river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Develop new spec for RMIClassLoader replacement
Date Mon, 27 Aug 2012 03:47:02 GMT

Hi Dennis:

Possibly dumb questions inlined...



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

View raw message