Product Description

JBoss (pronounced Jay Boss) Application Server or WildFly(since v.8.0) is an open source Java EE-based application server implemented in Java.

Because it is Java-based, JBoss Application Server can be run on any platform with a working Java Virtual Machine implementation. There are such platforms as Windows, most types of Unix, and Linux, though the platforms that do not use the standard Sun JVM implementation may experience issues.

Other JBoss-related projects include Hibernate, Tomcat, JBoss ESB, jBPM, JBoss Rules (formerly Drools), JBoss Cache, JGroups, JBoss Portal, SEAM, JBoss Transactions, JBoss Messaging and are marketed under the JBoss Enterprise Middleware Suite (JEMS) brand.

Software Pattern Summary

Platforms Supported by the Pattern

The pattern has been created in a manner that allows it to support Windows, Linux, and Unix platforms from the same module. A Software Instance is created for each unique server running on a host.

Identification

There are two possible triggers:

• A java process with org.jboss.as.host-controller in the arguments. If the pattern has this trigger and can find details of the domain controller, it creates a Red Hat JBoss Host Controller Software Instance. If it has this trigger but can't find details of the domain controller, it creates a Red Hat JBoss Host Controller with domain_controller attribute software instance.
• A java process with org.jboss.as.standalone, org.jboss.as.server or org.jboss.main in the arguments. If the pattern has this trigger, it creates a Red Hat JBoss Application Server or WildFly Software Instance.

Note that the java process can have any name. It is usually called java.exe but can also be called jboss.exe. Because of this the trigger only checks the process arguments, not the process command name.

Simple Identification Mappings

The components/processes displayed in the table below are identified using the simple identity mappings.

Versioning

Version information for the product is currently collected using one of three possible methods.

The methods are tried in order of precedence based on the likely success and/or accuracy of the information gathered. Once a result is obtained, the methods lower in precedence are not attempted.

In order of precedence, the methods are:

• Active Command - File Versioning
• Active Versioning (if enabled)
• Path Versioning
• Package Versioning

JAVA_HOME environment variable should be set for Unix systems prior to running versioning active command and active command for edition extraction. The regular expression used for extracting JAVA_HOME for Unix systems is as follows:

•  regex '^(/.*)/bin/java$'

Obtaining installation path

Active Command (file) and Active Versioning methods depend on the successfully obtained installation path of the JBoss Application Server (WildFly) by a pattern.

The installation path is obtained as follows:

JBoss Application Server 7.0 and later, the trigger process arguments contain the parameter -Djboss.home.dir and the value of the parameter is parsed as follows:

• Windows platform
  
  

  • If the trigger process arguments contain quotes, the regular expressions attempted are: (?i)"-Djboss\.home\.dir=(\w:[\\/][^"]+)"

    and (?i)-Djboss\.home\.dir="(\w:[\\/][^"]+)"

  • If the trigger process arguments do not contain quotes, the regular expression used is: (?i)-Djboss\.home\.dir=(\w:.+?)\sor

    '(?i)-Djboss\.home\.dir=(\w:.+)\s*$'
    
    

• UNIX platform
  
  

  • If the trigger process arguments contain quotes, the regular expression used is: '-Djboss\.home\.dir="(.+?)"

  • If the trigger process arguments do not contain quotes, the regular expression used is: -Djboss\.home\.dir=(/\S+)

  • If the above fails, a similar regular expression (possibly for older versions of the product) is used: -Djboss\.home\.url=file:(/\S+)

For JBoss Application Server versions before 7.0, the installation path is obtained from the trigger process arguments' classpath.

The pattern first parses the trigger process arguments to pull out the classpath using the following regular expressions:

• Windows platform
  
  

  • If the classpath is within quotes (contains spaces in the paths): (?i)-(?:cp|classpath)\s+"(.+?)"

  • If the classpath is not within quotes: (?i)-(?:cp|classpath)\s+(\S+)\s

• UNIX platform
  
  

  • If the classpath is within quotes (contains spaces in the paths): -(?:cp|classpath)\s+"(.+?)"

  • If the classpath is not within quotes: -(?:cp|classpath)\s+(\S+)\s

The classpath also has the path separator characters normalized for the platform type.

Then, the pattern parses the classpath section by section (sections are separated by ':' on UNIX platforms and ';' on the Windows platform) to obtain the installation path using the following regular expressions:

• Windows paltform (?i)^(\w:\\.+?)\\bin\\run\.jar

• UNIX platform ^(/\S+?)/bin/run\.jar

If the installation path still is not obtained, the pattern will attempt to parse it from trigger process arguments using the following regular expressions:

• 
  (?i)-Djava\.endorsed\.dirs="?(?:[^";]*?;)*?(\w:[^";]+?)\\lib\\endorsed[;"\s]

• 
  (?ix)\b(?:cp|classpath) \s "? (?:[^";]*?;)* (\w:\\.*?jboss[^;"]*?) \\(?:bin|lib)\\\w+\.jar

Active Command - File Versioning

If the installation path is retrieved, the pattern gets line from the file named jar-versions.xml using the following command:

• Unix paltform grep "jboss-main.jar" "<installation_path>/jar-versions.xml"
  

• Windows platform findstr /C:"jboss-main.jar" "<installation_path>\\jar-versions.xml"
  

• Windows platform

  findstr /C:"jboss.jar" "<installation_path>\\jar-versions.xml"

In case the line is successfully read, depending on the output, the pattern tries to extract version or platform_version by parsing it with the following regular expression:

• 
  specTitle="JBoss" implVersion\s*=\s*"(\d+(?:\.\d+)*)

Active Versioning

This method (if enabled in pattern configuration) also requires the installation path to be determined.

For versions of JBoss AS starting from 7.0, the pattern also needs to determine the mode which server was started in from trigger process arguments. Using all this information, the shell or batch file that instigated the instance runs with a -V argument, which results in the version number being returned.

For JBoss Application Server before 7.x.x, the Version Command results in a shell script being run in the bin directory that the main run.jar file is running from. For newer releases of program, shell batch file name is equal to the initial mode.

The pattern extracts the active platform_version using the following regular expression:

•  "JBoss(?: Application Server)?(?: AS)? EAP\s+(\d+(?:\.\d)*)"

And if the command output matches regex "JBoss(?: Application Server)?(?: AS)?\s+\d+", then pattern extracts the full version by means of regex:

• "JBoss(?: Application Server)?(?: AS)?\s+(\d+(?:\.\d)*)"

Obtaining MODE

This is required only for JBoss AS of 7.0.0 or newer.

The pattern obtains the mode under which server was started from trigger process' argument list by matching:

• org.jboss.as.standalone - Mode is standalone
• org.jboss.as.server OR org.jboss.as.process-controller OR org.jboss.as.host-controller OR jboss.domain.config.dir OR jboss.domain.master.address - Mode is domain

Versioning command

If we are able to acquire the installation path and mode if needed, then the pattern will attempt to run one of the following version commands:

• For version <7.0.0 on Windows the pattern executes (cd /d <base_dir> && echo "" | run -V)
• For version ≥7.0.0 on Windows the pattern executes (cd /d <base_dir> && echo "" | <mode> -V)
• For version <7.0.0 on UNIX the pattern executes (cd <base_dir>; echo "" | ./run.sh -V | grep build)
• For version ≥7.0.0 on UNIX the pattern executes (cd <base_dir>; echo "" | ./<mode>.sh -V | grep build)

The regular expression for the JBoss EAP platform_version: "JBoss(?: Application Server)?(?: AS)? EAP\s+(\d+(?:\.\d)*)"

The regular expression for the full_version:

• "JBoss(?: Application Server)?(?: AS)?\s+(\d+(?:\.\d)*)"

Path Versioning

Supported for all platforms.

If the Active Version Command does not return any version information, we parse the process arguments against a regex to see if it contains some version information specific to the installation.

As the JBoss application server command is actually a Java VM instance, there is no point in applying a regex to the commands path. In such a case, we apply a regex to the arguments to see if there is a version number that can be used.

The regular expressions used to extract JBoss EAP platform_version:

• regex "(?i)EnterprisePlatform[_\\/\.-]?(?:\w+-)*?(\d+(?:[_\.-]\d+)*)",
• regex "(?i)jboss-eap[_\\/\.-]?(?:base)?[_\\/\.-]?(?:\w+-)*?[_\\/\.-]?(\d+(?:[_\.-]\d+)*)"

The regular expressions used to extract full_version :

• regex "(?i)jboss[_\\/\.-]?(?:\w+-)*?(\d+(?:[_\.-]\d+)*)",
• regex "(?i)jboss[_\\/\.-]?(?:base)?[_\\/\.-]?(?:\w+-)*?[_\\/\.-]?(\d+(?:[_\.-]\d+)*)",
• regex "(?:)/jboss/as(\d+)_",
• regex "(?i)wildfly-(\d+(?:\.\d)*)"
• regex "(?i)wildfly(\d+)"

The result of this regex then parsed against a function that converts all underscores and hyphens to periods - to ensure that the version number for this product is consistent throughout the environment. The Regex looks for the word "jboss" somewhere in the classpath and then is looking for a string of digits separated by either underscores, hyphens or periods. Such search results in an accurate version number that can catch several different formats without being open to erroneous inputs.

The version number returned using this method is dependent on the deployment pattern used to install the product. Usually, it will be to two levels, i.e., x.x, but we have seen a few instances where the depth can is three levels, i.e., x.x.x.

Using a sample command line argument of "/opt/jboss-3.2.6/bin/run.jar" and the above Regex, the version output would be "3.2.6".

Package Versioning

Supported for all platforms.

If the Active or Path Versioning techniques do not return any version information, then we check the installed packages to see if we can extract version information from one of them using the regex, '(?i)jboss' or '^(?i)jboss-as', '(?i)^eap7-wildfly' or '(?i)wildfly\d+'.

As there is only one package specified in the query, then the version number will be assigned if that package exists on the host.

A JBoss package is not registered as standard, and identification has been successful on a case-by-case basis. It is dependent on the environment setup.

Package querying is the lowest preferred way to achieve versioning, thus, the JBoss has been added, despite it not always being present, as a last resort if the other two methods fail.

Disadvantages

The main risk of package versioning is that if more than one version of the JBoss Application Server (WildFly) is installed, then the version information may not be mapped to the correct instance that has been identified.

In case two packages are installed, the pattern will take the highest version of the package.

File Versioning

We attempt to get information from the one of the server log files:

• The log file referred to in argument -Dorg\.jboss\.boot\.log\.file
• <install_root>/standalone/log/boot.log
• <install_root>/server/%server_name%/log/boot.log where server_name comes from -DServer argument
• <install_root>/server/%server_name%/log/boot.log where server_name comes from -Djboss.server.name argument

We parse it with one of the following regular expressions:

• JBoss\s*\[\w+\]\s*(\d+(?:\.\d+)*)
• JBoss_(\d+)_(\d+)_(\d+)
• Release\s*(\d+(?:\.\d+)*)

If it fails, we attempt to get version information from the files described in the table below.

Additional information

Obtaining Edition

Starting from version 6.0, the JBoss edition can be obtained by running the following command:

• <Obtaining installation path>/bin/appclient.sh

This command exists only for Enterprise Edition. Edition is set to Enterprise if command result has subword "JBoss EAP".
If edition was not set based on command output, pattern checks the following file:

• <Obtaining installation path>/version.txt

If it's content matches 'JBoss\s+Enterprise', edition will be set to Enterprise.

If edition was not set by the previous two methods, the pattern checks if appclient.sh exists by obtaining information about the following files:

• <Obtaining installation path>/bin/appclient.sh

• <Obtaining installation path>/bin/runObtaining MODE .sh(this file should definitely exist for both editions)

Edition can be obtained from the log directory.

Regex to obtain log directory from process arguments:

•  '(?i)-Dorg\.jboss\.boot\.log\.file=(\w:.+log)"'

Command to obtain Edition:

For Windows hosts:

• findstr /C:"JBoss EAP" "%server_log%"

 For Unix hosts:

• 'PRIV_CAT %server_log% |grep "JBoss EAP"'

If the pattern fails to obtain both files and obtaining edition from log file fails, it means an access problem and the undefined edition.

If a product version is lower than 6.0, the edition can be obtained from <Obtaining installation path>\readme.html file by parsing its content with the following regexes:

• "<title>JBoss Enterprise Application Platform" -for Enterprise
• "<title>JBoss\s+\d+(?:\.\d+)*?" -for Community

If the edition was not obtained, the pattern checks whether Obtaining installation path has subword 'EnterprisePlatform' or 'EAP'. if subword is found, it set edition value to Enterprise. For all other cases, the edition value will be set to empty string.
If version was not obtained, the pattern uses all of the described methods to get edition information.

If neither run.bat or mode.bat is found, it indicates a permission problem rather than the absence of the files.

Obtaining Server name

For JBoss of version 7.0.0 or newer server name can be retrieved only if server was started in domain mode. The value can be parsed using one of the following regular expressions against trigger process's arguments:

• 
  [/\\]domain[/\\]servers[/\\]([^\\/ ]+)[/\\]

• \-D\[Server\:([^\]]+)\]

For older versions of JBoss the pattern tries in order two following regular expressions against trigger process's arguments:

• 
  -Djboss\.server\.name=(\S+)

• 
  \s-c +(\S+)

Server Base

On the UNIX platform, the server base is discovered from the trigger process' command line arguments via use of one of the following regular expressions:

• 
  -Djboss\.server\.base\.dir="(.+?)"

• 
  -Djboss\.server\.base\.dir=(/\S+)

• 
  -Djboss\.server\.base\.url=file:(/\S+)

Server Home

On the UNIX platform, the server home is discovered from the trigger process' command line arguments via use of one of the following regular expressions:

• 
  -Djboss\.server\.home\.dir="(.+?)"

• 
  -Djboss\.server\.home\.dir=(/\S+)

• 
  -Djboss\.server\.home\.url=file:(/\S+)

Multicast_socket attribute

In a "standalone"mode mode, the pattern extracts this multicast_socket attribute from standalone-ha.xml or standalone-full-ha.xml files else from domain.xml file.

Pattern will use xpaths to extract multicast-address and port information:

•  //socket-binding-group/socket-binding[@name='jgroups-mping']/@multicast-address
• //socket-binding-group/socket-binding[@name='jgroups-mping']/@multicast-port

Listen_ssl_tcp_sockets attribute

If pattern was able to obtain base directory and determine the mode the listen_ssl_tcp_sockets, the attribute is extracted from host.xml or standalone.xml file.

Pattern will use xpaths to extract address and port information:

•  /server/interfaces/interface[@name="<name>"]/inet-address/@value
• /server/socket-binding-group[@default-interface="public"]/socket-binding[@name="https"]/@port
• /server/socket-binding-group/socket-binding[@name="<name>-https"]/@port

Application Model Produced by Software Pattern

Product Architecture

JBoss Application Server or WildFly is run independently from a folder. It is only dependent on a valid java virtual machine being installed on the system and referenced correctly in the PATH or JAVA_HOME environment variables.

It is usually started by the running of a shell script or batch file called run.sh or run.bat (depending on Operating System). When this script starts running, the Java VM passes all the relevant variables to it to start the JBoss Application Server or WildFly, depending on the version.

By default, JBoss can be run once on each host. With further installation in separate directories and some changes being made to the configuration file, you can run two or more JBoss instances relatively easily.

Software Pattern Model

One pattern has been created with the JBoss Application Server(WildFly) and JBoss Application Server (daemon) or WildFly(daemon) as its trigger processes. The pattern triggers only where the process cmd matches a java executable (java or java.exe) followed by one of the JBoss arguments:

• org.jboss.Main
• org.jboss.as.standalone
• org.jboss.as.server

Configuration Option

There is a configuration option for this product which allows to enable active versioning method.

To enable this option, you should set "True" to active_versioning_enabled variable.

SI Depth

Although the pattern, in general, produces instance-based Software Instance-based primarily on installation paths, the approaches, in particular, are all different for older and newer versions of JBoss. For the latter, it also depends on the mode of the server.

SI Depth for Standalone mode

This approach is only for JBoss AS version 7.0 or newer started in 'standalone' mode.
If Obtaining installation path was successfully discovered then the key is based on it and host's key, else the pattern uses key group based on trigger process's argument list.

SI Depth for Domain mode

This approach is only for JBoss AS version 7.0 or newer started in 'domain' mode.

If Obtaining installation path and Obtaining Server name were successfully discovered, then the key is based on them and a host's key. If only installation path was found, the pattern uses key group based on it, or alternatively based on classpath. In other cases the pattern doesn't set key letting BMC Discovery manage found instances automatically.

SI Depth for older versions

This approach is only for JBoss AS version older than 7.0.
If Obtaining installation path and/or Obtaining Server name were successfully discovered, the pattern creates the key based on them and a host's key. It creates key group based on either the installation path (if obtained) or parsed from process's arguments java classpath.

Extended J2EE Discovery

Starting from version 8.3, Atrium Discovery is able to perform extended (J2EE) JBoss Application Server discovery via additional patterns . The approach used by these patterns is based on analyzing different configuration files of JBoss Application Server or WildFly.

Relationship Creation

Under normal circumstances, the Application Server SI creates a client-server link to the Host Controller on the same host (the Application Server is the client). However, sometimes there isn't a Host Controller on the host because the Host Controller acts as Domain Controller. In this situation, the Application Server creates a client-server link to such Host Controller which is identified as Domain Controller by having domain controller attribute set to TRUE.

The Host Controller SI creates a client server link to the Domain Controller. It finds the domain controller by parsing the trigger process arguments. If that fails, it parses the file <installation root>/domain/configuration/host.xml.

An installation might look like the following:

Server Groups

For BMC Discovery 11.0 and later, JBoss Server Groups are modeled as a cluster.  Every time a Red Hat JBoss Application Server or WildFly SI is created, the pattern created searches the host.xml for details of the group it belongs to.  If it finds this group information, it links it to the relevant JBoss Server Group Cluster.

App Server Software Components are contained within Red Hat JBoss Server Groups.

The pattern also creates a management relationship between the JBoss Cluster and the Host Controller which serves as Domain Controller:

Note that legacy versions of BMC Discovery (10.2 and earlier) model JBoss Server Groups as software instances with client-server links to various application servers (the Server Group is the server).  These models will be upgraded to a full cluster model when you upgrade to a modern BMC Discovery version.

Standalone Cluster

For Standalone mode, if the instances are clustered, JBoss Standalone Cluster will be created. Every time a Red Hat JBoss Application Server or WildFly SI is created and has a standalone mode, the pattern created searches for multicast_socket attribute and created Red Hat JBoss Standalone Cluster.  After that, it will search for the Red Hat JBoss Application Server or WildFly SIs with the identical multicast_socket attribute and add it to the cluster.

App Server's Software Components are contained within Red Hat JBoss Standalone Cluster.

Subject Matter Expertise

SME feedback would be appreciated in identifying any other possible commands or files that could be used to version an instance of the product.

Further information on known packages and their reliability would help improve the overall scope and depth of versioning for this product.

Testing

The pattern has been tested against Live installations of the product on Linux and Windows.