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

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

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

Hudson commented on RIVER-336:
------------------------------

FAILURE: Integrated in River-trunk-jdk7 #153 (See [https://builds.apache.org/job/River-trunk-jdk7/153/])
RIVER-336 Update to ClassLoading.  Convert remaining tests to utilise the new java.rmi.server.RMIClassLoaderSpi provider in ClassLoading

Reduce number of tasks executed in RandomStressTest to avoid OOME on 32 bit platforms.

Updated configuration.policy to ensure that all configuration files had sufficient permission to be tested,  broken.prop wasn't being tested, not sure how long this has been the case, but it's fixed now. (peter_firmstone: [http://svn.apache.org/viewvc/?view=rev&rev=1590379])
RIVER-336 Minor update to ClassLoading.  Be careful with MarshalledObject obtained from ActivationGroupDesc (peter_firmstone: [http://svn.apache.org/viewvc/?view=rev&rev=1590241])
RIVER-336 Minor update to ClassLoading to allow modular frameworks to specify the ClassLoader used to load a RMIClassLoaderSpi provider. (peter_firmstone: [http://svn.apache.org/viewvc/?view=rev&rev=1590226])
RIVER-336 Refactoring of work done by Sim & Gregg.  Updated all River code in the main src distribution to utilize ClassLoading, instead of RMIClassLoader, including marshaling and unmarshaling of MarshalledObject's using MarshalledInstance, this ensures that the replacement service provider mechanism is fully utilized, instead of using RMIClassLoader.  Since both replacement provider classes for RMIClassLoader, proposed to date, have identical methods to RMIClassLoaderSpi, RMIClassLoaderSpi has been retained, to ensure that existing providers can be utilized without requiring recompilation.  ServiceLoader is used to load RMIClassLoaderSpi, however this is done directly by ClassLoading, not RMIClassLoader and clients may specify which instance they want from a list of available providers by setting the system property "net.jini.loader.ClassLoading.provider". 

ClassLoading was chosen to delegate to the provider, since it already contained two methods compatible with and delegated to RMIClassLoader and it only required two more static methods to replace RMIClassLoader functionality and delegate directly to an RMIClassLoaderSpi provider.

Tests that test PreferredClassProvider have been converted to utilize ClassLoading instead of RMIClassLoader.

ClassLoading also has a third method that delegates to the three argument version of Class.forName, this new method fixes a hotspot and source of lock contention in mahalo's RandomStressTest, by thread confining calls for each ClassLoader when loading classes, as a result the Class.forName hot spot has been reduced from 50% cpu to under 3% cpu.

In addition debug mode has been set back to false for transaction testing. (peter_firmstone: [http://svn.apache.org/viewvc/?view=rev&rev=1590000])


> 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: River_2.2.0
>            Reporter: Gregg Wonderly
>         Attachments: CBAClassLoaderBUILD.patch, CBAClassLoaderQA.patch, CBAClassLoaderSRC_dir.patch, 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 was sent by Atlassian JIRA
(v6.3.4#6332)