river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject RMI ClassLoader improvements
Date Fri, 12 Jun 2015 09:30:43 GMT
Hi Dennis,

The full story is documented in net.jini.loader.ClassLoading, I've 
appended the javadoc below.

The quick summary is that Greg and Sim's works were integrated and 
functionality of both was retained, but their class names weren't in 
order to retain compatibility with existing implementations of 
RMIClassLoaderSPI as both abstract SPI's duplicated the methods in the 
abstract class RMIClassLoaderSPI and implementations couldn't extend 
both.  In this case RMIClassLoaderSPI implementations can be loaded from 
any ClassLoader (with permission), unlike RMIClassLoader, that can only 
be loaded with.the system ClassLoader.

> You're right about two conversations, I'm interested in the RMIClassLoader improvements
> were done. It's that simple. I'll await Peter's reply.

  * Provides static methods for loading classes using {@link
  * RMIClassLoaderSpi} with optional verification that the codebase URIs
  * used to load classes provide content integrity (see {@link
  * Security#verifyCodebaseIntegrity
  * Security.verifyCodebaseIntegrity}).
  * <p>
  * Traditionally a class extending {@link RMIClassLoaderSpi} is 
determined by setting
  * the system property "java.rmi.server.RMIClassLoaderSpi", or 
  * {@link RMIClassLoaderSpi} may also be defined by {@link RMIClassLoader}
  * using a provider visible to the {@link ClassLoader} returned by
  * {@link ClassLoader#getSystemClassLoader} with {@link ServiceLoader}.
  * </p><p>
  * As explained in River-336 this isn't always practical for IDE's or 
  * frameworks.  To solve River-336, ClassLoading now uses {@link 
  * to determine a {@link RMIClassLoaderSpi} provider, however unlike
  * {@link RMIClassLoader}, by default it uses ClassLoading's {@link 
  * instance to find providers.
  * </p><p>
  * To define a new RMIClassLoaderSpi for River to utilize, create a file in
  * your providers jar file called:
  * </p><p>
  * META-INF/services/java.rmi.server.RMIClassLoaderSpi
  * </p><p>
  * This file should contain a single line with the fully qualified name of
  * your RMIClassLoaderSpi implementation.
  * </p><p>
  * ClassLoading will iterate through all RMIClassLoaderSpi 
implementations found
  * until it finds one defined by the system property:
  * </p><p>
  * System.getProperty("net.jini.loader.ClassLoading.provider");
  * </p><p>
  * If this System property is not defined, ClassLoading will load
  * <code>net.jini.loader.pref.PreferredClassProvider</code>, alternatively
  * <code>java.rmi.server.RMIClassLoader</code> delegates all calls to 
  * RMIClassLoader}.
  * </p><p>
  * If a provider is not found, it will not be updated.
  * </p><p>
  * <h1>History</h1>
  * <p>Gregg Wonderly originally reported River-336 and provided a patch
  * containing a new CodebaseAccessClassLoader to replace {@link 
  * later Sim Isjkes created RiverClassLoader that utilized ServiceLoader.
  * Both implementations contained methods identical to {@link 
  * however new implementations were required to extend new provider
  * implementations, creating a compatibility issue with existing 
  * extending {@link RMIClassLoaderSpi}.  For backward compatibility 
with existing
  * implementations, {@link RMIClassLoaderSpi} has been retained as the 
  * avoiding the need to recompile client code.  The abilities of both
  * implementations, to use ServiceLoader, or to define a provider using 
a method
  * call have been retained, with the restriction that implementations 
are to be
  * obtained via ServiceLoader.
  * </p><p>
  * Instead, all that is required for utilization of existing service 
  * {@link RMIClassLoaderSpi} implementations is to set the system property
  * "net.jini.loader.ClassLoading.provider".
  * </p>
  * @author Sun Microsystems, Inc.
  * @since 2.0

View raw message