CodebaseAwareObjectInputStream

Special ObjectInputStream subclass that falls back to a specified codebase to load classes from if not found locally. In contrast to standard RMI conventions for dynamic class download, it is the client that determines the codebase URL here, rather than the "java.rmi.server.codebase" system property on the server.

Uses the JDK's RMIClassLoader to load classes from the specified codebase. The codebase can consist of multiple URLs, separated by spaces. Note that RMIClassLoader requires a SecurityManager to be set, like when using dynamic class download with standard RMI! (See the RMI documentation for details.)

Despite residing in the RMI package, this class is not used for RmiClientInterceptor, which uses the standard RMI infrastructure instead and thus is only able to rely on RMI's standard dynamic class download via "java.rmi.server.codebase". CodebaseAwareObjectInputStream is used by HttpInvokerClientInterceptor (see the "codebaseUrl" property there).

Thanks to Lionel Mestre for suggesting the option and providing a prototype!

JndiRmiClientInterceptor

org.aopalliance.intercept.MethodInterceptor for accessing RMI services from JNDI. Typically used for RMI-IIOP but can also be used for EJB home objects (for example, a Stateful Session Bean home). In contrast to a plain JNDI lookup, this accessor also performs narrowing through PortableRemoteObject.

With conventional RMI services, this invoker is typically used with the RMI service interface. Alternatively, this invoker can also proxy a remote RMI service with a matching non-RMI business interface, i.e. an interface that mirrors the RMI service methods but does not declare RemoteExceptions. In the latter case, RemoteExceptions thrown by the RMI stub will automatically get converted to Spring's unchecked RemoteAccessException.

The JNDI environment can be specified as "jndiEnvironment" property, or be configured in a jndi.properties file or as system properties. For example:

<property name="jndiEnvironment"> <props> <prop key="java.naming.factory.initial">com.sun.jndi.cosnaming.CNCtxFactory</prop> <prop key="java.naming.provider.url">iiop://localhost:1050</prop> </props> </property>

JndiRmiProxyFactoryBean

FactoryBean for RMI proxies from JNDI.

Typically used for RMI-IIOP (CORBA), but can also be used for EJB home objects (for example, a Stateful Session Bean home). In contrast to a plain JNDI lookup, this accessor also performs narrowing through javax.rmi.PortableRemoteObject.

With conventional RMI services, this invoker is typically used with the RMI service interface. Alternatively, this invoker can also proxy a remote RMI service with a matching non-RMI business interface, i.e. an interface that mirrors the RMI service methods but does not declare RemoteExceptions. In the latter case, RemoteExceptions thrown by the RMI stub will automatically get converted to Spring's unchecked RemoteAccessException.

The JNDI environment can be specified as "jndiEnvironment" property, or be configured in a jndi.properties file or as system properties. For example:

<property name="jndiEnvironment"> <props> <prop key="java.naming.factory.initial">com.sun.jndi.cosnaming.CNCtxFactory</prop> <prop key="java.naming.provider.url">iiop://localhost:1050</prop> </props> </property>

JndiRmiServiceExporter

Service exporter which binds RMI services to JNDI. Typically used for RMI-IIOP (CORBA).

Exports services via the javax.rmi.PortableRemoteObject class. You need to run "rmic" with the "-iiop" option to generate corresponding stubs and skeletons for each exported service.

Also supports exposing any non-RMI service via RMI invokers, to be accessed via JndiRmiClientInterceptor / JndiRmiProxyFactoryBean's automatic detection of such invokers.

With an RMI invoker, RMI communication works on the RmiInvocationHandler level, needing only one stub for any service. Service interfaces do not have to extend java.rmi.Remote or throw java.rmi.RemoteException on all methods, but in and out parameters have to be serializable.

The JNDI environment can be specified as "jndiEnvironment" bean property, or be configured in a jndi.properties file or as system properties. For example:

<property name="jndiEnvironment"> <props> <prop key="java.naming.factory.initial">com.sun.jndi.cosnaming.CNCtxFactory</prop> <prop key="java.naming.provider.url">iiop://localhost:1050</prop> </props> </property>

RmiClientInterceptorUtils

Factored-out methods for performing invocations within an RMI client. Can handle both RMI and non-RMI service interfaces working on an RMI stub.

Note: This is an SPI class, not intended to be used by applications.

RmiProxyFactoryBean

FactoryBean for RMI proxies, supporting both conventional RMI services and RMI invokers. Exposes the proxied service for use as a bean reference, using the specified service interface. Proxies will throw Spring's unchecked RemoteAccessException on remote invocation failure instead of RMI's RemoteException.

The service URL must be a valid RMI URL like "rmi://localhost:1099/myservice". RMI invokers work at the RmiInvocationHandler level, using the same invoker stub for any service. Service interfaces do not have to extend java.rmi.Remote or throw java.rmi.RemoteException. Of course, in and out parameters have to be serializable.

With conventional RMI services, this proxy factory is typically used with the RMI service interface. Alternatively, this factory can also proxy a remote RMI service with a matching non-RMI business interface, i.e. an interface that mirrors the RMI service methods but does not declare RemoteExceptions. In the latter case, RemoteExceptions thrown by the RMI stub will automatically get converted to Spring's unchecked RemoteAccessException.

The major advantage of RMI, compared to Hessian, is serialization. Effectively, any serializable Java object can be transported without hassle. Hessian has its own (de-)serialization mechanisms, but is HTTP-based and thus much easier to setup than RMI. Alternatively, consider Spring's HTTP invoker to combine Java serialization with HTTP-based transport.

RmiRegistryFactoryBean

FactoryBean that locates a java.rmi.registry.Registry and exposes it for bean references. Can also create a local RMI registry on the fly if none exists already.

Can be used to set up and pass around the actual Registry object to applications objects that need to work with RMI. One example for such an object that needs to work with RMI is Spring's RmiServiceExporter, which either works with a passed-in Registry reference or falls back to the registry as specified by its local properties and defaults.

Also useful to enforce creation of a local RMI registry at a given port, for example for a JMX connector. If used in conjunction with org.springframework.jmx.support.ConnectorServerFactoryBean, it is recommended to mark the connector definition (ConnectorServerFactoryBean) as "depends-on" the registry definition (RmiRegistryFactoryBean), to guarantee starting up the registry first.

Note: The implementation of this class mirrors the corresponding logic in RmiServiceExporter, and also offers the same customization hooks. RmiServiceExporter implements its own registry lookup as a convenience: It is very common to simply rely on the registry defaults.