"jhalliday" wrote : I've been waiting for ServiceBindingManager to stabilize in AS trunk before updating the transaction integration code to play nice with it. Of course there is an element of chicken and egg here - SBM's not done until it works with the transaction manager :-) True enough. Luckily the SBM that's in place now doesn't work anymore, so that resolves our dilemna. I can just check in what I have to replace it and we don't end up any more broken. anonymous wrote : The MC bean lifecycle methods in the TransactionManagerService already override some of the property file configuration, for example logging and IP address binding. In the latter case we fish the address out of the ServerConfig.SERVER_BIND_ADDRESS system property, largely though ignorance of any more elegant solution. Is there an MC style way to get this value from the server meta data? Simplest is to dependency inject it, with the system property as the value. End result is the same as you have now, but it can be changed by the user. <property name="bindAddress">${jboss.bind.address}</property> I think better is to get the value from the SBM; that way the SBM becomes the source for all binding related metadata. See example below. anonymous wrote : For the port binding, I was planning on changing transaction-beans.xml to contain a port, probably something like: | | property name="port" value="some ref to SBM here" | | and then use that value to override the one from the jta properties file. MC would then automatically ensure SBM deployed before the transaction manager. Yep. The syntax would look like this: | <bean name="TransactionManager" class="com.arjuna.ats.jbossatx.jta.TransactionManagerService"> | <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=TransactionManager", exposedInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean.class, registerDirectly=true)</annotation> | | <property name="transactionTimeout">300</property> | <property name="objectStoreDir">${jboss.server.data.dir}/tx-object-store</property> | <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property> | | <property name="recoveryBindAddress"> | <value-factory bean="ServiceBindingManager" | method="getInetAddressBinding" | parameter="TransactionManager"/> | </property> | | <property name="recoveryPort"> | <value-factory bean="ServiceBindingManager" | method="getIntBinding" | parameter="TransactionManager"/> | </property> | </bean> | It can get more involved than that if there are a bunch of bindings (see wiki), but that handles a single pair of properties for an address and port. If the address property was of type String rather than InetAddress, the "method" attribute in its value-factory element would have a value of "getStringBinding". The presence of the bean="ServiceBindingManager" in the value-factory elements triggers the proper dependency relationship in the MC. anonymous wrote : As I understand it this is essentially your proposal 1). Since I've not actually started work on it yet I'm happy to change the approach if you feel one of the others is preferable. No, I think proposal 1) is best; just threw out the others to spark discussion in case that wasn't workable. anonymous wrote : As it happens there is already a JBTM JIRA for adding system property substitution support, but a) I'm not sure it will make the cut for the next release and b) I don't think it's as elegant an approach for this particular problem. Cool. I think system property substitution is a nice thing to have in all our config files, but I agree it's not as elegant for this usage. anonymous wrote : | There are two issues here: all the transaction using JVMs have to agree which interface to bind the port on. They can't use different real addresses, since the port is uniq only in the scope of the address. In the absence of any override we use localhost. This works from a technical standpoint but confuses users who don't understand why the server is listening on that address even if they have specified something else with -b. | | Secondly, each process must obviously have a different port number. Right now we start at a given number and walk the range until we find an unoccupied one. The drawback of this is we may wind up on a port that something else which has not yet started also needs. | | If we wish to configure this though SBM too we clearly need some more properties... Multiple properties are not a problem. The examples above use an overloaded method on the SBM that only takes a single parameter to identify the binding. There are other variants that take a second param to identify a particular binding. As for the localhost vs -b issue, that's a configuration choice. The SBM can certainly handle using a different address value for this binding vs. the others, allowing you to keep "localhost" if you want. Here's how it could all be set up: In bindings.xml: | <bean class="org.jboss.bindings.ServiceBinding"> | <constructor> | <parameter>TransactionManager</parameter> | <parameter>RecoveryManager</parameter> | <parameter>${jboss.bind.address}</parameter> | <parameter>4712</parameter> | </constructor> | </bean> | | <bean class="org.jboss.bindings.ServiceBinding"> | <constructor> | <parameter>TransactionManager</parameter> | <parameter>UUIDFactor</parameter> | <parameter>localhost</parameter> | <parameter>1234</parameter> | </constructor> | </bean> | The TransactionManager bean then becomes: | <bean name="TransactionManager" class="com.arjuna.ats.jbossatx.jta.TransactionManagerService"> | <annotation>@org.jboss.aop.microcontainer.aspects.jmx.JMX(name="jboss:service=TransactionManager", exposedInterface=com.arjuna.ats.jbossatx.jta.TransactionManagerServiceMBean.class, registerDirectly=true)</annotation> | | <property name="transactionTimeout">300</property> | <property name="objectStoreDir">${jboss.server.data.dir}/tx-object-store</property> | <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property> | | <property name="recoveryBindAddress"> | <value-factory bean="ServiceBindingManager" | method="getInetAddressBinding"> | <parameter>TransactionManager</parameter> | <parameter>RecoveryManager</parameter> | <value-factory> | </property> | | <property name="recoveryPort"> | <value-factory bean="ServiceBindingManager" | method="getIntBinding" > | <parameter>TransactionManager</parameter> | <parameter>RecoveryManager</parameter> | <value-factory> | </property> | | <property name="uuidBindAddress"> | <value-factory bean="ServiceBindingManager" | method="getInetAddressBinding"> | <parameter>TransactionManager</parameter> | <parameter>UUIDFactor</parameter> | <value-factory> | </property> | | <property name="uuidPort"> | <value-factory bean="ServiceBindingManager" | method="getIntBinding" > | <parameter>TransactionManager</parameter> | <parameter>UUIDFactor</parameter> | <value-factory> | </property> | </bean> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170116#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...