Managed Domain
You might consider running a Managed Domain instance. This would allow you to maintain two server instances with a web application each, as well as the ease of maintaining the port and interface declarations from a single console view.
To aim would be one Managed Domain with two servers. Each server would belong to a different server group. Each server group would have it's own interface or port declarations as you require.
This gives you a single management console, with a set of relative server groups to assign your current and future servers to, with the ability to change, reassign or disable on the fly.
Configuration
The files you need to be aware of are both the host.xml and domain.xml configuration files under the following file path.
~/JBOSS_HOME/domain/configuration
From the domain.xml we can see the socket binding groups. The following example is a default "standard-sockets" group, but you are free to create as many groups as you want, with as many or as little declarations as you need.
<socket-binding-groups>
<socket-binding-group name="standard-sockets" default-interface="public">
<socket-binding name="ajp" port="8009"/>
<socket-binding name="http" port="8080"/>
<socket-binding name="https" port="8443"/>
<socket-binding name="osgi-http" interface="management" port="8090"/>
<socket-binding name="remoting" port="4447"/>
<socket-binding name="txn-recovery-environment" port="4712"/>
<socket-binding name="txn-status-manager" port="4713"/>
<outbound-socket-binding name="mail-smtp">
<remote-destination host="localhost" port="25"/>
</outbound-socket-binding>
</socket-binding-group>
...
You could create two socket binding groups for your needs, catering to the two sets of ports you might need. Once they exist, you want a server group to know about them. Lets look further down the domain.xml file.
We can see in the following example that a server group references a socket binding group. For bonus points, we can see that some applications are deployed to them. This has occurred via the Management Console, but AS 7 persists the console and CLI changes to the configuration.
<server-groups>
<server-group name="main-server-group" profile="full">
<jvm name="default">
<heap size="1303m" max-size="1303m"/>
<permgen max-size="256m"/>
</jvm>
<socket-binding-group ref="full-sockets"/>
<deployments>
<deployment name="your_application.jar" runtime-name="your_application.jar"/>
<deployment name="your_application_02.ear" runtime-name="your_application_02.ear"/>
<deployment name="test.war" runtime-name="test.war"/>
</deployments>
</server-group>
<server-group name="other-server-group" profile="full-ha">
<jvm name="default">
<heap size="1303m" max-size="1303m"/>
<permgen max-size="256m"/>
</jvm>
<socket-binding-group ref="full-ha-sockets"/>
<deployments>
<deployment name="your_application_02.ear" runtime-name="your_application_02.ear"/>
<deployment name="test.war" runtime-name="test.war"/>
</deployments>
</server-group>
</server-groups>
The domain.xml file is the configuration of the domain controller, which is the "boss" of the managed domain. The actual server information is contained in the host controller, so let's look at the host.xml file.
<servers>
<server name="server-one" group="main-server-group">
</server>
<server name="server-two" group="main-server-group" auto-start="true">
<!-- server-two avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group -->
<socket-bindings port-offset="150"/>
</server>
<server name="server-three" group="other-server-group" auto-start="false">
<!-- server-three avoids port conflicts by incrementing the ports in
the default socket-group declared in the server-group -->
<socket-bindings port-offset="250"/>
</server>
</servers>
We can see three servers in the default domain. The third is a member of the other-server-group group, while the first two are members of the main-server-group group. Notice the port binding declarations also.
You could delete the third server, and dedicate server one and server two to your first and second web applications respectively. Each server can belong to a unique group. Each group can declare a unique port. After this, you're ready to deploy your applications to their respective groups and you're away.
Using Management Tools
The examples are showing XML, but you should use the Management Console or the Management CLI when configuring your installation. The console is simple enough, so here's some CLI operations to help.
To show the server groups:
[domain@localhost:9999 /] /server-group=*:read-resource(include-runtime=true)
To show the socket binding groups:
[domain@localhost:9999 /] /socket-binding-group=*:read-resource(include-runtime=true)
You want to expose the specific http attribute values, so we can amend our CLI operation to run on that child node. Including the runtime parameter helps us catch anything passed at runtime that hasn't been written to or persisted to the server model.
[domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=http:read-resource(include-runtime=true)
And here's how you write to it.
[domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=http:write-attribute(name=port,value=8081)
That should get you started. As you might gather, I'm a fan of the Managed Domain...
