Hmm. I was about to say that serverSocketClass is only used by the server and therefore doesn't need to be on the InvokerLocator. But when JBM uses the bisocket transport, there is a callback server on the client side which uses the serverSocketClass parameter to create socket wrappers. It turns out that the reason things work is that both serverSocketClass and clientSocketClass are configured by JMSRemotingConnection: | metadata.put(MicroSocketClientInvoker.CLIENT_SOCKET_CLASS_FLAG, | "org.jboss.jms.client.remoting.ClientSocketWrapper"); | metadata.put(SocketServerInvoker.SERVER_SOCKET_CLASS_FLAG, | "org.jboss.jms.server.remoting.ServerSocketWrapper"); | So adding clientSocketClass to the InvokerLocator, i.e., setting isParam=true, is redundant. The point is that nothing is broken, but ideally both clientSocketClass and serverSocketClass would be treated the same. Sorry I didn't notice this before. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4052733#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...