8 Replies Latest reply: Sep 20, 2012 1:39 PM by Brian Stansberry Branched to a new discussion. RSS

Change standalone ports without touching standalone.xml

Karel Piwko Master

Hi,

 

is it possible to change ports where AS 7 is listening to (jmx, management, httpPort, ...) via other means than modifying standalone.xml?

 

Either via passing system properties or by specifying complete set, ports-01, etc. as known from previous versions.

 

Thanks,

 

Karel

  • 1. Re: Change standalone ports without touching standalone.xml
    Radoslav Husar Master

    Hi Karel,

     

    Good question. You can now configure ports passing a system property as you were used to in older versions of AS. You can edit your xml configuration and specify an expression like this for example:

     

    <socket-binding name="http" port="${jboss.http.port:8080}"/>

     

    then you can pass in, for instance

     

    ./bin/standalone.sh --server-config=standalone-ha.xml -Djboss.http.port=8888

     

    HTH,

    Rado

  • 2. Re: Change standalone ports without touching standalone.xml
    Karel Piwko Master

    Rado,

     

    thanks for the hint. It won't work out of the box but I guess it's the best possible workaround we have.

  • 3. Re: Change standalone ports without touching standalone.xml
    Radoslav Husar Master

    Yeah, you would still have to modify the xml which is not what you were looking for. Using port offset can simplify the modifications a little. However there is no expression for that either.

       <socket-binding-group name="standard-sockets" default-interface="public" port-offset="1000">

  • 5. Re: Change standalone ports without touching standalone.xml
    Brian Stansberry Master

    I have no objection to adding more system property expressions to our default configs if there is a large scale use case for them. The port-offset is already controlled by default via a system property:

     

    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">

     

    What's the use case for adding default properties to the other ones? Besides general convenience, which is a valid reason. But I want to understand if there are specific issues (e.g. with Arquillian integration) that these properties are meant to resolve. I'm curious because a default property in a standard config file isn't really a solid contract; it's just a convenience. If someone edits the config to remove the property, the contract is gone. So if people are regarding these as a contract, I'd like to hear that.

  • 6. Re: Change standalone ports without touching standalone.xml
    Justin Bertram Master

    Why is using -Djboss.socket.binding.port-offset from the command line not sufficient for this?  All the relevant configuration files already contain:

     

    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
    
  • 7. Re: Change standalone ports without touching standalone.xml
    Michal Matloka Newbie

    I'd like to refer to specific case. Developer non-friendly environment, hudson/jenkins, but no jboss instance on server for dev use. It is usefull to run arquillian tests, but in this environment only way is to use embedded arquillian weld container (still buggy + does not support transactions etc) or jboss managed. As shown in arquillian getting started guide it is possible to make maven download .zip jboss, unpack to target, and then run tests on this instance. However port 8080 of course is used. Currently jboss-as arquillian managed container does not provide possibility to change http port directly. It is possible to specify javaVmArguments- jboss.socket.binding.port-offset, but! it is required to change also management port, so that arquillian may manage jboss. But when using jboss.socket.binding.port-offset we really dont know on what ports server will run in given environment? There are two cases to improve this:

    1. Allow to specify main jboss-as ports via arquillian conf what requires mentioned properties - user must find unused tcp ports, e.g. on IANA list

    2. Specify offset in aquillian conf (via new property, not existing 'javaVmArguments' property), and then modify management port in arquillian conf automatically according to stored default port for manage interface in  jboss-as arquillian managed containers code. But  'conflict' may occur when user specifies botth offset and management port and when situation on server differs - e.g. other server was run.

    3. Use offset for all ports apart from management port - management port pass directly to jboss vm argument. This would required adding property in jboss conf only for management port.

    3rd seems to be the most reasonable.

     

     

    Edit: sorry, I've noticed that properties for management ports are already in jboss configuration. It is possible to run arquillian with following settings:

     

    <container qualifier="jbossas-managed-download">

                        <configuration>

                                  <property name="jbossHome">target/jboss-as-7.1.1.Final</property>

                                  <property name="javaVmArguments">-Djboss.socket.binding.port-offset=100 -Djboss.management.native.port=9054 -Xmx512m -XX:MaxPermSize=128m</property>

                                  <property name="managementPort">9154</property>

                        </configuration>

              </container>

     

    Although it is not too 'intuitive'.

  • 8. Re: Change standalone ports without touching standalone.xml
    Brian Stansberry Master

    Michal Matloka wrote:

     

    Edit: sorry, I've noticed that properties for management ports are already in jboss configuration. It is possible to run arquillian with following settings:

     

    <container qualifier="jbossas-managed-download">

                        <configuration>

                                  <property name="jbossHome">target/jboss-as-7.1.1.Final</property>

                                  <property name="javaVmArguments">-Djboss.socket.binding.port-offset=100 -Djboss.management.native.port=9054 -Xmx512m -XX:MaxPermSize=128m</property>

                                  <property name="managementPort">9154</property>

                        </configuration>

              </container>

     

    Although it is not too 'intuitive'.

     

    The "not too 'intuitive'" part is what I was getting at when I talked about contracts. Default system properties in a config file are not a contract that a general purpose piece of software like ARQ can rely on. Say the arq configuration added something like this instead:

     

     

             <container qualifier="jbossas-managed-download">

                        <configuration>

                                  <property name="jbossHome">target/jboss-as-7.1.1.Final</property>

                                  <property name="javaVmArguments">-Xmx512m -XX:MaxPermSize=128m</property>

                                  <!-- Tell arquillian to start the server with a port-offset of 100 />

                                  <property name="port-offset">100</property>

                                  <property name="managementPort">9199</property>

                        </configuration>

              </container>

     

    The idea being that the Arq docs would say that this "port-offset" property means that Arq will launch the server with a port offset of 100. That statement in the arq docs is the contract ARQ would provide. The problem is ARQ cannot assume it can internally use -Djboss.socket.binding.port-offset=100 to fulfil that contract. The underlying AS config may not have port-offset="${jboss.socket.binding.port-offset:0}".  The user could have changed the config so it just has port-offset="0" or port-offset="${com.mycompany.port-offset:0}".

     

    To fulfil that contract, ARQ would have to do something much more sophisticated; somehow analyze the actual server config, take some sort of config modification action to ensure the port-offset is 100, and then absolutely make sure that at shutdown that config modification action is reverted so the user's configuration is not modified.

     

    So, adding something like <socket-binding name="http" port="${jboss.http.port:8080}"/> to all of our standard socket-binding configs, is understandable because it might be a useful convenience. But if people are going to try and interpret that convenience as a kind of contract, then I think it will just lead to trouble.