[jira] Commented: (RIVER-336) Jini should support platforms other than those with RMIClassLoader as the classloading control point. IDEs inparticular need help.

["Gregg Wonderly (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RIVER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907418#action_12907418 ] 

Gregg Wonderly commented on RIVER-336:
--------------------------------------

christopher.dolan@avid.com commented on the river-dev list:

For others going down this same road, here's a bit of acquired wisdom:
it's important that you do NOT set the system property
java.rmi.server.RMIClassLoaderSpi because if you do then you'll get
NoClassDefFoundError when com.sun.jini.lookup.entry.LookupAttributes
calls the java.rmi.MarshalledObject constructor and
java.rmi.server.RMIClassLoader crashes on class initialization trying to
find your custom SPI.

In my code, I do this during bootstrap:

        String myLoaderSPI =
System.getProperty("java.rmi.server.RMIClassLoaderSpi");
        if (null != myLoaderSPI && null ==
ClassLoader.getSystemResource(myLoaderSPI)) {
              // HACK! We can't force our SPI into the system class
loader, so we
              // need to back it out because otherwise it breaks
MarshalledObject
              // usage in the com.sun.jini.lookup.entry.LookupAttributes
class.
              System.setProperty("java.rmi.server.RMIClassLoaderSpi",
"default");
        }

Another big gotcha is that you may not be able to talk to older Reggie
instances because of the hardcoded RMIClassLoader reference in
ServiceTypeBase in reggie-dl.jar.  I worked around this via a custom
URLStreamHandlerFactory that detects an out-of-date reggie-dl.jar and
substitutes a newer version invisibly at runtime.  This is a very
unpleasant hack, but I could find no alternative.  I suppose this could
also be solved via a preferred class...

Chris

> 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: Greggs_Mods-with-some-minor-changes.patch, Greggs_Mods.patch, PreferredClassProvider.java, PreferredClassProvider.java.rej, 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.