|
RMI Release Notes |
Documentation Contents |
RMI Changes in J2SETM 1.4.1
- Changes to RMI for J2SETM 1.4.2 included minor bug fixes.
RMI Enhancements in J2SETM 1.4
- HTTP Fallback Is More Configurable
- The implementation-specific system property
sun.rmi.transport.proxy.eagerHttpFallbackhas been added to allow additional control over when RMI's default socket factory will fall back to HTTP tunneling. This property configures the default socket factory so that any SocketException thrown by an initial (direct) connection attempt will trigger HTTP tunneling; this more "eager" fallback strategy can be useful when dealing with firewalls which deny instead of ignore connection attempts to unauthorized ports.
java.rmi.Naming.listMethod No Longer Prepends a Scheme to Names Returned- In previous releases, the
Naming.listmethod prepended the schemermi:to each name contained in the returned array of strings. TheNaming.listimplementation now matches the specification, returning an array of names that are URL-formatted, but without the scheme component.
java.rmi.server.RemoteServer.setLogMethod Now Requires a Permission- The
RemoteServer.setLogmethod now specifies that it throws aSecurityExceptionif the caller does not have permission to set the global call log. The method requires that the calling context has the permissionjava.util.logging.LoggingPermission("control")to set the log.
java.rmi.server.RMISocketFactory.setFailureHandlerMethod Now Requires a Permission- The
RMISocketFactory.setFailureHandlermethod now specifies that it throws aSecurityExceptionif the caller does not have permission to set the globaljava.rmi.server.RMIFailureHandler. The method requires that the calling context has the permissionjava.lang.RuntimePermission("setFactory")to set the failure handler.
RMI Enhancements in Previous Releases
- Server-side Stack Traces Now Retained in Remote Exceptions
- The RMI runtime implementation will now preserve the server-side stack trace information of an exception that is thrown from a remote call, in addition to filling in the client-side stack trace as it did in previous releases. Therefore, when such an exception becomes accessible to client code, its stack trace will now contain all of its original server-side trace data followed by the client-side trace.
This feature is made possible by the new "programmatic access to stack trace information" feature of java.lang.Throwable in J2SE 1.4, which included making a
Throwable's stack trace data part of its default serialized form. What the client-side RMI runtime implementation now does to cooperate with this feature is to append the client-side trace to the unmarshalled server-side trace, rather than simply overwriting with the client-side trace as it did in previous releases.Certain RMI server applications may wish to prevent any server-side stack trace data from accompanying an exception to be marshalled as the result of a remote call (as part of the exception's default serialized form in J2SE 1.4), perhaps for reasons of performance or confidentiality. In such cases, the implementation-specific system property
can be set to "true" to cause the server-side RMI runtime implementation to clear the stack traces of all exceptions thrown from the current virtual machine as the result of remote method invocations.sun.rmi.server.suppressStackTraces
- Service Provider Interface for
RMIClassLoader- Certain static methods of
java.rmi.server.RMIClassLoadernow delegate their behavior to an instance of a new service provider interface,java.rmi.server.RMIClassLoaderSpi. The service provider can be configured to augment RMI's dynamic class loading behavior for a given application. By default, the service provider implements the standard behavior of all of the static methods inRMIClassLoader. See the class documentation ofRMIClassLoaderandRMIClassLoaderSpifor more details.
- Dynamic Server Host Name
- The
java.rmi.server.hostnameproperty can now be dynamically updated to indicate that future exports should use a new host name. Therefore, the new host name value will be contained in the stub for an object that is exported after the property is updated.
- Serializing Primitive Class Objects
- In previous releases, a
ClassNotFoundExceptionwould be thrown if an attempt was made to pass a primitiveClassobject in an RMI call. Now, an object that containsClassobjects for primitive types can be passed as a remote method parameter or return value, and can be stored in ajava.rmi.MarshalledObjectinstance.
- Enhanced RMI Implementation Logging
- Sun's implementation of RMI in J2SE 1.4 now uses the new Logging APIs to provide implemention-specific logging output. See the RMI Implementation Logging page for more information.
- Serialization Enhancements
- See the Serialization Release Notes for more information on enhancements and improvements to Object Serialization in J2SE 1.4.
Changes to RMI Tools (since 1.3)
java.rmi.activation.ActivationGroupDesc(since 1.3)- The
getClassNamemethod, which returns the group's class name, can now returnnull, indicating the system's default group implementation. Previously, thegetClassNamemethod would return the name of the internal implementation class if the default group implementation was chosen when the descriptor was constructed.Due to this change, if an application running in a 1.3 JVM registers an new activatable object with the
ActivationSystem,rmidmust also be upgraded to run 1.3, since a pre-1.3rmidwill not be able to activate the newly registered activatable object.
- Constructors of activatable objects (since 1.3)
- An activatable object's "activation" constructor, which takes an
ActivationIDand aMarshalledObjectas arguments and which is called by theActivationInstantiatoreach time the object is activated, can now beprivateorprotected. Previously, the implementation only allowedpublicactivation constructors.
java.rmi.server.RMIClassLoader(since 1.3)java.rmi.server.RMIClassLoaderhas a new method,getClassLoader. This method returns the class loader that RMI uses to load classes from a specified codebase URL path. This API can be used in an implementation that requires complete RMI marshalling/unmarshalling behavior. Seejava.rmi.server.RMIClassLoaderfor details.
- Serializing remote objects (since 1.2.2)
- Prior to 1.2.2, an attempt to pass an unexported remote object in a RMI call would result in a
java.rmi.StubNotFoundException. This exception was a result of the RMI runtime's failure to locate a stub object during an attempt to replace a remote object implementation with its corresponding stub. In 1.2.2 and later releases, an unexported remote object passed in an RMI call will no longer result in an exception, but rather the remote object will be serialized instead of its stub. If the remote object implementation is not serializable, an attempt to pass an unexported object in an RMI call will result in ajava.rmi.RemoteExceptionwith the nested exceptionjava.io.NotSerializableException.
- The RMI Stub Compiler,
rmic
- By default,
rmicnow assumes that the destination directory for generated stubs is the package-named subdirectory of the current working directory. If the "-d" option is not specified, the result is the same as though it were specified with the current working directory "." as an argument. The "-d" may still be used to override the default destination directory.- Two new options, "
-idl" and "-iiop" have been added to generate IDL and stubs for IIOP, respectively.
- The RMI Activation Daemon,
rmid- By default,
rmidnow requires a security policy file.
*As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.
| Copyright ©
2003 Sun Microsystems, Inc. All Rights
Reserved.
Please send comments to: rmi-comments@java.sun.com |