Author:[email protected]>
<The RMI/JRMP based implementation of the org.jboss.ejb.ContainerInvoker interface supports customization of the socket factory implementation using the standard RMI java.rmi.server.RMIClientSocketFactory and java.rmi.server.RMIServerSocketFactory interfaces. This HowTo describes the customization usage and demonstrates an example custom factory from the 1.3 RMIThe Custom Socket Factory Tutorial
One of the many items that can be customized about the JBoss container configurations is the container invoker and its configuration. Figure 13.26 illustrates the jboss.xml elements that are available for customizing the container-invoker element when it is set to org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker
Figure 13.26. jboss.xml container-invoker-config elements
Custominzation of the ContainerInvoker sockets entails sepecifying the classes that implement the java.rmi.server.RMIClientSocketFactory and java.rmi.server.RMIServerSocketFactory interfaces. Figure 13.27gives a sample container-invoker-conf element.
Figure 13.27. Sample container-invoker-conf Element
The jbosstest cvs module contains a org.jboss.test.jrmp package in the src/main directory which contains tests of custom socket configuration. One example is the CompressionSocket example from the RMI custom socket tutorial. The org.jboss.test.jrmp.test.TestCustomSockets class access a stateless session bean using the compression custom sockets as well as a stateful session bean using the default JRMP socket factories. The ejb-jar.xml and jboss.xml deployment descriptors for the ejb jar are given in Figure 13.28and Figure 13.29 See the jbosstest module code for the complete details.
Figure 13.28. TestCustomSockets Example ejb-jar.xml Descriptor
Figure 13.29. TestCustomSockets Example jboss.xml Descriptor
Note that we specified an RMIObjectPort of 4445 rather than the default value of 4444 used by the default container configurations in the standardjboss.xml descriptor. This is necessary because JRMP RMI implementation keeps track of the exported object endpoints based on (port, host, ClientSocketFactory, ServerSocketFactory) rather than just (port, host). If we had used a port value of 4444 we would see an exception at deployment time indicating that port 4444 could not be bound because it was already in use. The reason is that the RMI layer would try to create two ServerSocket instances with the same port,host combination for the two different (ClientSocketFactory, ServerSocketFactory) combinations. If you don't have a reason to choose a fixed port the safest RMIObjectPort configuration to use it 0 which allows the system to bind any available port.