[
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)
