I have an MBean that depends on one or more connectors:
<mbean code="org.jboss.tm.remoting.server.DistributedTransactionManager" name="jboss:service=DistributedTransactionManager"> <depends-list optional-attribute-name="Connectors"> <depends-list-element>jboss.remoting:service=Connector,transport=socket</depends-list-element> </depends-list> </mbean>
In its startService method, the MBean issues addInvocationHandler calls to add a new invocation handler (for the "DTM" subsystem) to each of those connectors. However, the DTM subsystem does not use the unified invoker marshaller, which is specified by the "datatype=invocation" parameter appended to the invoker locator URI of the connector MBean for the socket transport:
<!-- excerpt from jboss-service.xml --> <mbean code="org.jboss.remoting.transport.Connector" xmbean-dd="org/jboss/remoting/transport/Connector.xml" name="jboss.remoting:service=Connector,transport=socket" display-name="Socket transport Connector"> <attribute name="InvokerLocator">[CDATA[socket://localhost:4446/?datatype=invocation]]</attribute> <attribute name="Configuration"> <handlers> <handler subsystem="invoker">jboss:service=invoker,type=unified</handler> </handlers> </attribute> <depends>jboss.remoting:service=NetworkRegistry</depends> </mbean>
The problem is that the return value of connector.getLocator() does not make sense for the DTM subsystem, as it includes the "datatype=invocation" parameter. Everything works fine if I remove the "datatype=invocation" part of the locator.
Should it be possible to use a single connector for multiple subsystems, each with its own marshaller? In that case, perhaps the "datatype=xxx" parameter could be added by the client side (which must specify the subsystem it wants to interact with anyway), rather than being kept in a global attribute of the connector MBean. In the case of the unified invoker, the client-side proxy could specify "datatype=invocation".
Or perhaps I should simply add another socket connector MBean (without the "datatype=xxx") just for myself? I noticed that Bill did that for AOP remoting. Adding another connector defeats the idea of having one connector per transport, though. One connector per transport (and multiple subsystems per connector) sounds like a good thing to me.