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: Separating out RMIClassLoader dependencies
Date Sun, 12 Aug 2012 10:46:16 GMT

Just thought I'd bring this back from previous list discussion, as it 
displays some of the issues you had to overcome.



Gregg Wonderly wrote:
> 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