Structure of the standalone.xml

• 4 pre-configured files
• standalone.xml
• standalone-ha.xml
• standalone-full.xml
• standalone-full-ha.xml
• How do you choose the right profile?

Structure of the standalone.xml

            
//




    
    

    
    

    
    

    
    

    
    


            
        

• extensions
• Provide Java EE 7 specification, Each extension corresponds to a module
• management
• security-realms, audit-log, management-interfaces and the access-control
• profile
• define subsystems, each subsystem corresponding to its relative extension
• interfaces
• server network interfaces
• socket-binging-group
• define pretty much most of the ports

Running WildFly from custom configuration folder

• Why custom configuration folder
• leave default directories unaltered
• specify a different configuration folder because of system administrators

            
//
$ cd $JBOSS_HOME

$ cp -r standalone/ /tmp/myServer

$ ./bin/standalone.sh -Djboss.server.base.dir=/tmp/myServer/
            
        

Binding WildFly on custom port

• Why bind WildFly on a custom port
• different service running on the same IP:PORT

Using the Admin Console

Login Admin Console
Configuration -> General Configuration -> Socket Binding -> View
Select http, edit, change 8080 to 9080, save, reload on Runtime tab

Using the CLI

            
//
/socket-binding-group=standard-sockets/socket-binding=http:write-attribute(name=port,value=9080)
reload
/socket-binding-group=standard-sockets/socket-binding=http:read-attribute(name=port)
            
        

Using System Properties

            
//
$ ./bin/standalone.sh -Djboss.http.port=9080
$ ./bin/standalone.sh -Djboss.socket.binding.port-offset=1000
            
        

Binding WildFly on custom IP

• Why wildfly bind on a custom IP
• bind WildFly to a different address(public IP, public hostname) rather than the default localhost

            
//
$ ./bin/standalone.sh -b 10.0.0.1

$ ./bin/standalone.sh -Djboss.bind.address=10.0.0.1

$ ./bin/standalone.sh -bmanagement=10.0.0.1

$ ./bin/standalone.sh -Djboss.bind.address.management=10.0.0.1
            
        

Configuring multiple WildFly instances to run on the same machine with different ports

• Why configure multiple WildFly instances to run on the same machine
• In some cases, most of all cause of architecture reasons, you may need to run multiple WildFly's instances on a single server. You can do this by isolating each instance and giving it different bindings port.

            
//
$ cd $JBOSS_HOME
$ cp -a standalone node-1
$ cp -a standalone node-2

$ ./bin/standalone.sh -Djboss.server.base.dir=./node-1 -Djboss.http.port=8180 -Djboss.management.http.port=9991
$ ./bin/standalone.sh -Djboss.server.base.dir=./node-2 -Djboss.http.port=8280 -Djboss.management.http.port=9992

$ ./bin/standalone.sh -Djboss.serever.base.dir=./node-1 -Djboss.socket.binding.port-offset=100
$ ./bin/standalone.sh -Djboss.serever.base.dir=./node-2 -Djboss.socket.binding.port-offset=200
            
        

Configuring multiple WildFly instances to run on the same machine with different IPs

• Why configure multiple WildFly instances to run on the same machine with different IPs
• In some cases, most of all cause of architecture reasons, you may need to run multiple WildFly instances on a single server. You can do this by isolating each instance and giving it different bindings IPs

            
//
$ sudo ifconfig YOUR_NIC:1 10.0.1.1 netmask 255.255.255.0
$ sudo ifconfig YOUR_NIC:2 10.0.1.2 netmask 255.255.255.0

$ cd $JBOSS_HOME
$ cp -a standalone node-1
$ cp -a standalone node-2

$ ./bin/standalone.sh -Djboss.serever.base.dir=./node-01 -Djboss.bind.address=10.0.0.1 -Djboss.bind.address.management=10.0.0.1
$ ./bin/standalone.sh -Djboss.serever.base.dir=./node-02 -Djboss.bind.address=10.0.0.2 -Djboss.bind.address.management=10.0.0.2

$ ./bin/standalone.sh -Djboss.serever.base.dir=./node-01 -b 10.0.0.1 -bmanagement=10.0.0.1
$ ./bin/standalone.sh -Djboss.serever.base.dir=./node-02 -b 10.0.0.2 -bmanagement=10.0.0.2
            
        

Using Management CLI

Connecting to the CLI

            
//
$ cd $JBOSS_HOME
$ ./bin/jboss-cli.sh

[disconnected /] connect
[standalone@localhost:9990 /]
[standalone@localhost:9990 /] ls
[standalone@localhost:9990 /] ls subsystem=

$ ./bin/jboss-cli.sh --gui
            
        

Checking the server-status via CLI

            
//
[standalone@localhost:9990 /] :read-attribute(name=server-state)
{
    "outcome" => "success",
    "result" => "running"
}
            
        

Deploy an application via CLI

            
//
[standalone@localhost:9990 /] deploy /path/example.war

[standalone@localhost:9990 /] deployment-info --name=example.war
NAME        RUNTIME-NAME PERSISTENT ENABLED STATUS
example.war example.war  true       true    OK 

[standalone@localhost:9990 /] deploy example.war --disabled
            
        

Undeploy an application via CLI

            
//          
[standalone@localhost:9990 /] undeploy example.war

[standalone@localhost:9990 /] undeploy -l
NAME        RUNTIME-NAME ENABLED STATUS
example.war example.war  true    OK     
            
        

Executing commands in batch-mode via CLI

            
//         
[standalone@localhost:9990 /] batch
[standalone@localhost:9990 / #] deploy example.war
[standalone@localhost:9990 / #] deploy simple.war
[standalone@localhost:9990 / #] run-batch
The batch executed successfully
[standalone@localhost:9990 /] 
            
        

Reloading a server configuration via CLI

            
//         
[standalone@localhost:9990 /] reload 
            
        

Shutting down and restarting an instance via CLI

            
//
[standalone@localhost:9990 /] shutdown
[standalone@localhost:9990 /] shutdown --restart=true