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:[email protected]] Sent: Thursday, April 01, 2010 4:16 AM To: [email protected] 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. >> > >
