river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Develop new spec for RMIClassLoader replacement
Date Tue, 28 Aug 2012 12:37:27 GMT
On 27/08/2012 10:43 AM, 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
> 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.
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.
> 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


Thank you for speaking up, this is the only comprehensive solution to so 
many issues we have all struggled with, issues that plagued Jini, 
decimated in one fell swoop, I'm gobsmacked.    Do you realise how many 
Jira issues this probably solves?

I'm ashamed to say that you've mentioned it previously on this list.

Is the artifact URL scheme provider available publicly?  If so, we need 
to include it with River, to ensure it's available at the platform 
level.  Do you know if the URL scheme is compatible with RFC 3986 URI 

Did you write the RMIClassLoaderSPI implementation?  Again I'd very much 
appreciate it if you wanted to contribute it back to River.

Whether people like Maven or not is beyond the point, this is the only 
comprehensive solution available, it needs to be the preferred solution 
for anyone new to River,this lowers the bar significantly, developers no 
longer even need to know what a ClassLoader is!  Anyone that doesn't 
like it needn't use it, but I suspect given time, it'll grow on even the 
most staunch disbeliever.



View raw message