Todd Trimmer created AS7-6818: --------------------------------- Summary: Allow socket-binding-group-refType to override default-interface Key: AS7-6818 URL: https://issues.jboss.org/browse/AS7-6818 Project: Application Server 7 Issue Type: Feature Request Components: Domain Management Affects Versions: 7.1.1.Final Reporter: Todd Trimmer Assignee: Brian Stansberry Priority: Optional I want all the host controllers in my domain to use the same socket-binding-group. However, each host controller can have multiple servers, each with its own IP, but each IP still reuses the same port number (yet still a unique IP+port combo). The problem is that the socket-binding-group-refType will not let me override the @default-interface value from the referent socket-binding-group. I am forced to create a second, equally verbose, socket-binding-group exactly like the first group in every way, except for the @default-interface. I wish to avoid this. My particular scenario cannot rely on @port-offset because my hardware load-balancer needs all nodes in the same pool to use the same ports. This could be easily solved if the socket-binding-group-refType could have a @default-interface attribute to override the socket-binding-group[@default-interface] it references. The host.xml could thus look like this: ... <interfaces> <interface name="public"> <inet-address value="10.10.10.1" /> </interface> <interface name="public-two"> <inet-address value="10.10.10.2" /> </interface> </interfaces> ... <servers> <server name="server-one" group="prod-server-group" auto-start="true"> <jvm name="jvm6g" /> </server> <server name="server-two" group="@prod-server-group" auto-start="false"> <jvm name="jvm2g" /> <socket-binding-group ref="standard-sockets" default-interface="public-two" /> </server> </servers> ... This alleviates the burden of having to define a second socket-binding-group in domain.xml and maintaining the same set of socket-binding definitions in two places. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira