Continuing the discussion from https://github.com/jbossas/jboss-as/pull/248 on the regular dev list, so it has higher visibility. On 9/4/11 4:40 PM, dobozysaurus wrote: First, thanks for the patch; I didn't say that before. :) Better handling of "0.0.0.0" in the inet-address element is definitely needed. So let's just assume any need for step #4 will go away. To achieve the goal of controlling the external sockets of a standalone server with a simple -b, the standard standalone*.xml configs we ship would need to be modified like this: <interfaces> <interface name="management"> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/> </interface> <interface name="public"> <inet-address value="${jboss.bind.address.public:127.0.0.1}"/> </interface> </interfaces> A necessary precondition to that is the management console included in master not barf if it queries the server and gets back a ModelNode of ModelType.EXPRESSION instead of ModelType.STRING. Heiko/Stan, where does that stand? Once the console can support it, I think it's a good idea to have the standard configs use an expression. Once that's there, I'm kinda ok with the use of -b as a cmd line arg to a standalone server. I see the ease of use benefits, and -b is a long-standing JBoss AS tradition. The thing that makes me queasy is it's a long-standing tradition, but now with new and different wrinkles: 1) It's now much easier to make the -b setting meaningless. If someone changes the name of the "public" interface to something else or gives it a criteria other than <inet-address value="${jboss.bind.address.public:127.0.0.1}"/> the -b setting will be completely ignored. You could break -b in earlier AS releases as well, but you had to try much harder to make it completely meaningless. This is the kind of thing that can be explained in a good FAQ, which is why I'm kinda ok with the whole idea. 2) It doesn't do anything if you run domain.sh, or if it will the semantics are presently undefined. A command line arg passed to domain.sh potentially impacts multiple processes: ProcessController, HostController, 0..n app server instances. -- Brian Stansberry Principal Software Engineer JBoss by Red Hat