Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of
 SRS0=zICJpF=GD=wonderly.org=gregg@yourhostingaccount.com designates
 65.254.253.116 as permitted sender)
Message-ID: <4AD5FF60.2070207@wonderly.org>
Date: Wed, 14 Oct 2009 11:42:08 -0500
From: Gregg Wonderly <gregg@wonderly.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Separating out RMIClassLoader dependencies
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Gregg Wonderly <gregg@wonderly.org>

As I try to put together some netbeans modules for Jini development tasks, I am 
fighting with netbeans classloader use alot (and not actually winning it seems). 
  So I am thinking (actually I'm trying some of this out) about whether it would 
make sense to help with OSGi and other classloader integration as well, if we 
could put an SPI in front of the use of RMIClassLoader.loadClass() etc so that 
different environments could provide more deliberate control over where classes 
are resolved.

The problem I am having in netbeans is that I need the PreferredClassProvider 
and jsk-resources.jar which provides the Jini RMIClassLoaderSpi to be in the JVM 
system class loader to make it active.  Yet that class loader is invisible to 
the netbeans module subsystem because it provides brickwall separation of the 
modules from each other through separate classloaders that will delegate to the 
netbeans system class loader.  All of the delegation back and forth is what I am 
fighting with.

What I am playing with is creating a static class that mimics the 
RMIClassLoaderSpi by providing the same methods, but which then also provides a 
security controlled setter to set the implementation.  An interface would then 
document the methods that this SPI requires, and then implementation of that 
interface could be "set" on this static class.

The simple nature of this change means that we can just replace RMIClassLoader 
references with the static class reference, and provide a simple implementation 
of the interface that just uses RMIClassLoader.xxxx() calls for implementation.

That would put the code in a position to accept pluggable implementations of 
class resolution I believe.

However, I'm still trying to think through how PreferredClassProvider and 
ClassLoading interact with RMIClassLoaderSPI to see if I've forgotten something big.

I'm curious if anyone from the Jini team at Sun has any insight into whether 
this would really make it possible to better control which class loaders are used.

Right now, there are several places in the Jini code where null ClassLoader 
references end up redirecting loading into the netbeans context class loader 
which is almost always the netbeans system class loader, and I'm having a hard 
time keeping the codebase loader visible.

Anyone have thoughts or questions?

Gregg Wonderly