Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4BB58EEC.9050503@zeus.net.au>
Date: Fri, 02 Apr 2010 16:30:04 +1000
From: Peter Firmstone <jini@zeus.net.au>
User-Agent: Thunderbird 2.0.0.14 (X11/20080531)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: [jira] Updated: (RIVER-336) Jini should support platforms other
 than those with RMIClassLoader as the classloading control point.  IDEs
 inparticular
 need help.
References: <1650762676.558811269895587159.JavaMail.jira@brutus.apache.org>
 <4BB46450.9000702@zeus.net.au>
 <B1CF6B3997B0D4499EF6043F5388D6B8052907D6@TEW-MAIL.global.avidww.com>
 <4BB58107.9030203@wonderly.org>
In-Reply-To: <4BB58107.9030203@wonderly.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Gregg,

Got a patch for your Reggie changes?

Cheers,

Peter.

Gregg Wonderly wrote:
> There are two primary issues that I needed to deal with for netbeans.
>
> First, because netbeans is an application with a native launcher, and 
> all kinds of things about it, as a platform, are private, I had 
> problems getting the RMIClassLoaderSPI in River, 
> PerferredClassProvider, to even activate.  There was an issue of 
> having to copy the jars into a private directory.  That wasn't 
> something that felt like a production step, and it would not make it 
> possible to install and use a plugin supporting river without 
> restarting the IDE.  This seemed a bit fragile if not just ugly.
>
> Second, the simple implementation of PreferredClassLoader creation in 
> net.jini.loader just uses the system classloader as the "parent" for 
> the created class loader.  In netbeans, the class loader hierachy that 
> a module sees, is just the module and its dependents, with the parent 
> of that loader being the system class loader.  The netbeans system 
> class loader is nearly empty.  It just has the bootstrap of netbeans 
> visible, and then netbeans creates compartmentalized views of various 
> modules as it loads things.  So, when I finally got 
> PreferredClassProvider activated, downloaded jars could not find stuff 
> that was "platform" in the since that the module had this stuff in its 
> classloader.  That module classloader was not visible because the 
> PreferredClassLoader's parent was just the netbeans startup jars and 
> the JRE.
>
> Thus, I really had a hard time making net.jini.loader work as it 
> existed.  I looked around and saw that there are actually very few 
> places that RMIClassLoaderSPI et.al. is used, and that all of those 
> places where of interest to me in how I could make Jini work inside of 
> netbeans (at least I hoped).
>
> So, I decided to just put a layer of indirection (what programmers do 
> to solve most problems :-) between net.jini.loader and 
> RMIClassLoaderSPI that would allow the mechanism itself to be supplanted.
>
> So, these patches allow one to override how all of the 
> RMIClassLoaderSPI mechanisms are implemented, plus adding some twists 
> specifically about how the "parent" classloader is chosen for 
> PreferredClassLoader instances.
>
> And, to top it off, some of you may recall that I modified preferred 
> class loading to actually have the facility to "never prefer" some 
> classes.  What this meant was that jar files in the codebase would 
> never be downloaded and thus in large, distributed systems, with lots 
> of jars visible across slow networks, a ServiceUI client application 
> could startup, and show all visible services, without downloading 
> anything.
>
> Additionally, I also make changes to Reggie to return marshalled data 
> values so that unmarshalling would not occur, which would trigger 
> downloads.
>
> By making these changes, I was able to move the "never prefer" 
> implementation into my CodebaseClassAccess implementation so that it 
> becomes a feature for me, not a platform implementation detail.
>
> Please ask questions if I've not provided enough details somewhere.
>
> Gregg Wonderly
>
> Christopher Dolan wrote:
>> Gregg,
>>
>> This patch is interesting to me.
>>
>> The implementation is clear: create a new plugin point to override the
>> default RMIClassLoader. Could you explain the motivation a little more?
>> It seems like the intention is to make River play nice in a large
>> process by not insisting that the global RMIClassLoader be configured to
>> suit River. And it looks like it is fully backward compatible for River
>> deployments that are already overriding RMIClassLoader by defaulting to
>> RMIClassLoaderCodebaseAccess.
>>
>> If nothing else, I would love to use something like this just to reduce
>> the huge number of places where I have to include
>> "-Djava.rmi.server.RMIClassLoaderSpi=...".  That alone would be a win.
>>
>> Or am I reading too much into this?
>>
>> Chris
>>
>> -----Original Message-----
>> From: Peter Firmstone [mailto:jini@zeus.net.au] Sent: Thursday, April 
>> 01, 2010 4:16 AM
>> To: river-dev@incubator.apache.org
>> Subject: Re: [jira] Updated: (RIVER-336) Jini should support platforms
>> other than those with RMIClassLoader as the classloading control point.
>> IDEs inparticular need help.
>>
>> Should I create a branch on svn for this?
>>
>> Regards,
>>
>> Peter.
>>
>> Gregg Wonderly (JIRA) wrote:
>>>      [
>> https://issues.apache.org/jira/browse/RIVER-336?page=com.atlassian.jira.
>> plugin.system.issuetabpanels:all-tabpanel ]
>>> Gregg Wonderly updated RIVER-336:
>>> ---------------------------------
>>>
>>>     Attachment: rmicl.diff.txt
>>>
>>> This is a diff out of my perforce node for the affected classes that
>> I've been using for some time.   The changes shown here are preliminary
>> and should be considered experimental.
>>>  
>>>> Jini should support platforms other than those with RMIClassLoader as
>> the classloading control point.  IDEs inparticular need help.
>> ------------------------------------------------------------------------
>> -----------------------------------------------------------
>>>>                 Key: RIVER-336
>>>>                 URL: https://issues.apache.org/jira/browse/RIVER-336
>>>>             Project: River
>>>>          Issue Type: New Feature
>>>>          Components: net_jini_loader
>>>>    Affects Versions: AR3
>>>>            Reporter: Gregg Wonderly
>>>>         Attachments: rmicl.diff.txt
>>>>
>>>>
>>>> The RMIClassLoader class and RMIClassLoaderSPI is currently the
>> control point for managing the "platform" view of how classes are
>> loaded.  In IDEs and other different environments, the "parent"
>> classloader view, is not always the "system class loader".  There are
>> some other variations on class loading that seem to indicate that while
>> RMIClassLoaderSPI can be plugged into, it doesn't always provide quite
>> the right facilities because even plugging into the system class loader
>> to override it might not be possible.
>>>> The diffs included here show some preliminary work that I did
>> investigating this issue to try and make it possible to discover and
>> load Jini servers within the netbeans IDE.
>>>> Refinement and some rework will be needed, and some other
>> investigation into other platforms such as JEE and other IDEs would be
>> helpful in making sure we understand what is really needed.  Even OSGi
>> would be something to look at.
>>>>     
>>>   
>>
>>
>
>