river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: Separating out RMIClassLoader dependencies
Date Thu, 15 Oct 2009 20:23:28 GMT
Okay, I've done some more digging and thinking and one of the primary issues I 
believe, comes down to how "containers", whether they are IDEs, standards like 
OSGi or JEE etc, provide access to the "classpath" of the running environment.

At the root of the behavior of PreferredClassProvider is

     private static ClassLoader getRMIContextClassLoader() ...

which just gets the context class loader.  This loader becomes the parent of the 
created PreferredClassLoader.

One of the issues for me, is that I think that honoring the PREFERRED.LIST is an 
important part of bringing advertised services into any JVM.

The primary driver of the use of PreferredClassProvider is of course the user of 
the RMIClassLoaderSpi class in the RMIClassLoader.  In reggie, the places that 
deal with unmarshalling, are using MarshalledInstance, MarshalledWrapper and 
MarshalInputStream to package this activity.

But, what I am seeing in netbeans is that reggie's unmarshalling is using the 
JVM system class loader as the parent, and that's causing non-preferred classes 
to be resolved in that class loader.  However, my netbeans modules have a 
different copy of the jsk-platform.jar that is visible to them, and that's where 
they are resolving things like Matches and other classes that are at the core of 
service unmarshalling by reggie.

So, I am trying to gather some more information to have some better perspectives 
on what actually makes the most sense.

Technically, netbeans sets the context class loader to the "netbeans" system 
class loader.  In most of my jini applications, I always use

Thread.currentThread().setContextClassLoader( getClass().getClassLoader() )

in newly created threads and in EDT listener objects (via the SyncThread class 
at http://swingutil.dev.java.net).  I think this should make things work out in 
integrating Jini into netbeans too, but I've somehow not recognized the right 
problem yet and got it solved.

Gregg Wonderly

Niclas Hedhman wrote:
> On Thu, Oct 15, 2009 at 12:42 AM, Gregg Wonderly <gregg@wonderly.org> wrote:
>> Anyone have thoughts or questions?
> For OSGi (maybe Netbeans as well) there might be additional
> "problems", since "loading a class" is not a straight forward process
> of calling a static provider. In OSGi, each "module" is wired up with
> a "class space" but the same class name (difference version, different
> provider, etc) may be in another "class space" in other modules. So,
> to fulfill a contract where a static method gets called from
> "anywhere" and I need to figure out which class to load is near
> impossible (at least in a platform independent way) in OSGi, as you
> will have to figure out which bundle (module) the caller reside in, in
> an environment where multiple versions of the same class can exist.
> (The reason this is near impossible is that the OSGi spec doesn't have
> any Classloader API, from which the Bundle can be retrieved.)
> "Class space" is a complex and powerful concept in OSGi, which
> basically try to ensure that there are no class version clashes and
> yet provide the class visibility needed.
> OTOH, Paremus has shown that
>  a) Locally available classes can be used,
>  b) Remote classes be downloaded and wrapped in temporary bundles with
> OSGi contracts honored.
>  c) PreferredClassLoader is not needed.
> So, perhaps your ambitions are too great and that you can/should
> ignore OSGi's needs.
> Cheers

View raw message