Save This Page
Home » spring-framework-2.5.5-with-dependencies » org.springframework » remoting » rmi » [javadoc | source]
org.springframework.remoting.rmi
public class: RmiProxyFactoryBean [javadoc | source]
java.lang.Object
   org.springframework.remoting.support.RemotingSupport
      org.springframework.remoting.support.RemoteAccessor
         org.springframework.remoting.support.UrlBasedRemoteAccessor
            org.springframework.remoting.support.RemoteInvocationBasedAccessor
               org.springframework.remoting.rmi.RmiClientInterceptor
                  org.springframework.remoting.rmi.RmiProxyFactoryBean

All Implemented Interfaces:
    BeanClassLoaderAware, FactoryBean, org.aopalliance.intercept.MethodInterceptor, InitializingBean

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 and Burlap, is serialization. Effectively, any serializable Java object can be transported without hassle. Hessian and Burlap have their own (de-)serialization mechanisms, but are HTTP-based and thus much easier to setup than RMI. Alternatively, consider Spring's HTTP invoker to combine Java serialization with HTTP-based transport.

Fields inherited from org.springframework.remoting.support.RemotingSupport:
logger
Method from org.springframework.remoting.rmi.RmiProxyFactoryBean Summary:
afterPropertiesSet,   getObject,   getObjectType,   isSingleton
Methods from org.springframework.remoting.rmi.RmiClientInterceptor:
afterPropertiesSet,   doInvoke,   doInvoke,   getStub,   invoke,   isConnectFailure,   lookupStub,   prepare,   refreshAndRetry,   setCacheStub,   setLookupStubOnStartup,   setRefreshStubOnConnectFailure,   setRegistryClientSocketFactory
Methods from org.springframework.remoting.support.RemoteInvocationBasedAccessor:
createRemoteInvocation,   getRemoteInvocationFactory,   recreateRemoteInvocationResult,   setRemoteInvocationFactory
Methods from org.springframework.remoting.support.UrlBasedRemoteAccessor:
afterPropertiesSet,   getServiceUrl,   setServiceUrl
Methods from org.springframework.remoting.support.RemoteAccessor:
getServiceInterface,   setServiceInterface
Methods from org.springframework.remoting.support.RemotingSupport:
getBeanClassLoader,   overrideThreadContextClassLoader,   resetThreadContextClassLoader,   setBeanClassLoader
Methods from java.lang.Object:
equals,   getClass,   hashCode,   notify,   notifyAll,   toString,   wait,   wait,   wait
Method from org.springframework.remoting.rmi.RmiProxyFactoryBean Detail:
 public  void afterPropertiesSet() 
 public Object getObject() 
 public Class getObjectType() 
 public boolean isSingleton()