I've been having to redo the JBoss AS ServiceBindingManager service to allow it to deal with pojo services. Before it could only work with mbeans. For details on the changes, see http://wiki.jboss.org/wiki/AS5ServiceBindingManager and the forum thread linked at the top of that wiki. Essential difference is that deployments that use ports go to the SBM as part of their configuration step to get the config value, rather than counting on SBM to know how to override their configuration. This intersects with JBM because you guys provide the remoting-bisocket-service.xml file, which specifies the address/port for your remoting connector. For that file to work properly with the new SBM impl, we need to come up with a workable format for the jboss.messaging:service=Connector,transport=bisocket mbean. The existing config: | <mbean code="org.jboss.remoting.transport.Connector" | name="jboss.messaging:service=Connector,transport=bisocket" | display-name="Bisocket Transport Connector"> | <attribute name="Configuration"> | <config> | <invoker transport="bisocket"> | <!-- There should be no reason to change these parameters - warning! | Changing them may stop JBoss Messaging working correctly --> | <attribute name="marshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute> | <attribute name="unmarshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute> | <attribute name="dataType" isParam="true">jms</attribute> | <attribute name="socket.check_connection" isParam="true">false</attribute> | <attribute name="serverBindAddress">${jboss.bind.address}</attribute> | <attribute name="serverBindPort">4457</attribute> | <attribute name="clientSocketClass" isParam="true">org.jboss.jms.client.remoting.ClientSocketWrapper</attribute> | <attribute name="serverSocketClass">org.jboss.jms.server.remoting.ServerSocketWrapper</attribute> | | <attribute name="numberOfCallRetries" isParam="true">1</attribute> | <attribute name="pingFrequency" isParam="true">214748364</attribute> | <attribute name="pingWindowFactor" isParam="true">10</attribute> | <attribute name="onewayThreadPool">org.jboss.jms.server.remoting.DirectThreadPool</attribute> | | <!-- End immutable parameters --> | | <attribute name="stopLeaseOnFailure" isParam="true">true</attribute> | | <!-- Periodicity of client pings. Server window by default is twice this figure --> | <attribute name="clientLeasePeriod" isParam="true">10000</attribute> | | <attribute name="timeout" isParam="true">0</attribute> | | <!-- Number of seconds to wait for a connection in the client pool to become free --> | <attribute name="numberOfRetries" isParam="true">10</attribute> | | <!-- Max Number of connections in client pool. This should be significantly higher than | the max number of sessions/consumers you expect --> | <attribute name="JBM_clientMaxPoolSize" isParam="true">200</attribute> | | <!-- The maximum time to wait before timing out on trying to write a message to socket for delivery --> | <attribute name="callbackTimeout">10000</attribute> | | | <!-- Use these parameters to specify values for binding and connecting control connections to | work with your firewall/NAT configuration | <attribute name="secondaryBindPort">xyz</attribute> | <attribute name="secondaryConnectPort">abc</attribute> | --> | | </invoker> | | <handlers> | <handler subsystem="JMS">org.jboss.jms.server.remoting.JMSServerInvocationHandler</handler> | </handlers> | </config> | </attribute> | </mbean> A version that asked the ServiceBindingManager to provide the configuration with the appropriate address/port would look like this: | <mbean code="org.jboss.remoting.transport.Connector" | name="jboss.messaging:service=Connector,transport=bisocket" | display-name="Bisocket Transport Connector"> | <attribute name="Configuration"> | | <value-factory bean="ServiceBindingManager" method="getElementBinding"> | <parameter> | jboss.messaging:service=Connector,transport=bisocket | </parameter> | <parameter><![CDATA[ | <config> | <invoker transport="bisocket"> | <!-- There should be no reason to change these parameters - warning! | Changing them may stop JBoss Messaging working correctly --> | <attribute name="marshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute> | <attribute name="unmarshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute> | <attribute name="dataType" isParam="true">jms</attribute> | <attribute name="socket.check_connection" isParam="true">false</attribute> | <attribute name="serverBindAddress">${host}</attribute> | <attribute name="serverBindPort">${port}</attribute> | <attribute name="clientSocketClass" isParam="true">org.jboss.jms.client.remoting.ClientSocketWrapper</attribute> | <attribute name="serverSocketClass">org.jboss.jms.server.remoting.ServerSocketWrapper</attribute> | | <attribute name="numberOfCallRetries" isParam="true">1</attribute> | <attribute name="pingFrequency" isParam="true">214748364</attribute> | <attribute name="pingWindowFactor" isParam="true">10</attribute> | <attribute name="onewayThreadPool">org.jboss.jms.server.remoting.DirectThreadPool</attribute> | | <!-- End immutable parameters --> | | <attribute name="stopLeaseOnFailure" isParam="true">true</attribute> | | <!-- Periodicity of client pings. Server window by default is twice this figure --> | <attribute name="clientLeasePeriod" isParam="true">10000</attribute> | | <attribute name="timeout" isParam="true">0</attribute> | | <!-- Number of seconds to wait for a connection in the client pool to become free --> | <attribute name="numberOfRetries" isParam="true">10</attribute> | | <!-- Max Number of connections in client pool. This should be significantly higher than | the max number of sessions/consumers you expect --> | <attribute name="JBM_clientMaxPoolSize" isParam="true">200</attribute> | | <!-- The maximum time to wait before timing out on trying to write a message to socket for delivery --> | <attribute name="callbackTimeout">10000</attribute> | | | <!-- Use these parameters to specify values for binding and connecting control connections to | work with your firewall/NAT configuration | <attribute name="secondaryBindPort">xyz</attribute> | <attribute name="secondaryConnectPort">abc</attribute> | --> | | </invoker> | | <handlers> | <handler subsystem="JMS">org.jboss.jms.server.remoting.JMSServerInvocationHandler</handler> | </handlers> | </config> | ]]> | </parameter> | </value-factory> | </attribute> | </mbean> Basically, the whole "config" element is passed as a parameter to the SBM, which does a replacement operation on the embedded ${host} and ${port}. That's quite ugly but works. An alternative is to no longer configure the connector as an mbean with an injected element, but rather as an MC pojo with an injected org.jboss.remoting.ServerConfiguration bean. The bean exposes the properties above. The port still comes from the SBM but all the CDATA messiness is gone. Another issue is where this file comes from. It won't look like one used outside the AS; don't know if that's an issue for you. If it is an issue, a third possibility is to keep the file as-is, except replace <attribute name="serverBindPort">4457</attribute> with <attribute name="serverBindPort">${jboss.messaging.connector.bisocket.port:4457}</attribute> The AS would then need to deploy a bean alongside the SBM that sets the jboss.messaging.connector.bisocket.port system property from the SBM before JBM deploys. That's kind of hacky, but does decouple JBM from all this stuff. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169967#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...