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 :-) 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? 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. 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. 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. --- There is an additional related problem that need some attention and may as well be tacked on to this discussion: The transaction manager makes extensive use of Uids. One component of uniqueness in the Uid is a process id. Java provides no standard way to get the process id of the JVM from the O/S, so we fudge this by binding to a particular port and using that port number as a pseudo process id. We never actually process traffic sent to the listening port, we are essentially just reserving it to guarantee uniqueness for the process lifetime. 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... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4170031#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...