- 1 Product Description
- 1.1 Known Versions
- 2 Software Pattern Summary
- 3 Platforms Supported by the Pattern
- 4 Identification
- 5 Versioning
- 5.1 Active Versioning
- 5.1.1 Obtaining BASE_DIR
- 5.1.2 Obtaining MODE
- 5.1.3 Versioning command
- 5.1.4 Versioning command
- 5.2 Path Versioning
- 5.3 Package Versioning
- 5.3.1 Disadvantages
- 5.4 Alternative Versioning Approach
- 5.5 Additional information
- 5.5.1 Obtaining Server name
- 6 Application Model Produced by Software Pattern
- 6.1 Product Architecture
- 6.2 Software Pattern Model
- 6.2.1 SI Depth
- 6.2.2 Extended J2EE Discovery
- 7 Subject Matter Expertise
- 8 Testing
- 9 Information Sources
- 10 Open Issues
- Discover with BMC ADDM
-
This product can be discovered by any edition of BMC Atrium Discovery and Dependency Mapping. Download our free Community Edition to try it out, or see what else it can discover!
- What is this?
- This is a product information page, containing details of the information that BMC Atrium Discovery gathers about a product and how it is obtained.
- Product Name
- JBoss Application Server
- Publisher Page
- Category
- Release
- TKU 2012-Mar-1
- Change History
- Reports & Attributes
- Publisher Link
- Red Hat
Product Description
JBoss (pronounced Jay Boss) Application Server 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 that has a working Java Virtual Machine implementation, including Windows, most flavours of Unix and Linux and Solaris, though those 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.
Known Versions
- 3.2
- 4.0
- 5.0
- 5.1
- 6.0
- 6.1
- 7.0
Software Pattern Summary
| Product Component | OS Type | Versioning | Pattern Depth |
|---|---|---|---|
| Application Server | Unix | Active, Path, Package | Instance-based or Grouped (data dependent) |
| Windows | Active, Package |
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
The only dependency JBoss Application Server has is that on the JVM, without which the Application Server will not function. Due to this dependency, for each running instance of JBoss Application Server - a JBoss Application Server and Java Virtual Machine (SI or RuntimeEnvironment) will be found.
The processes there are Simple Identifier definitions for are:
- RedHat JBoss Application Server (matches a java process, when org.jboss.Main is in the command line arguments) - Main JBoss Application Server instance - core Application Server that is run using Java to execute the run.jar file found in JBoss AS's ./bin/ directory.
- RedHat JBoss Application Server in Daemon mode (matches a java process, when org.jboss.Main and daemon are in the command line arguments) -JBoss Application Server instance running in Daemon mode - on Linux based systems the JBoss Application Server can be run as a Service in daemon mode.
Software Instance Triggers
| Trigger Node | Attribute | Condition | Argument |
|---|---|---|---|
| DiscoveredProcess | cmd | matches | regex '(?i)\bjava.exe$' |
| or | regex '\bjava(?:\.\S+)?$' | ||
| args | matches | regex'org\.jboss\.(?:Main|as\.(?:standalone|server))' |
Simple Identification Mappings
The following components/processes are identified using the simple identity mappings.
| Name | Command | Arguments |
|---|---|---|
| Red Hat JBoss Application Server | regex '(?i)\bjava(?:\.exe)?$' | regex 'org\.jboss\.(?:Main|as\.(?:standalone|server))' |
| regex '\bjava(?:\.\S+)$' | regex 'org\.jboss\.Main' | |
| Red Hat JBoss Application Server (daemon) | regex '(?i)\bjava(?:\.exe)?$' | regex 'daemon.+org\.jboss\.Main' |
| Red Hat JBoss Application Server Host Controller | regex '(?i)\bjava(?:\.exe)?$' | regex 'org\.jboss\.as\.host-controller' |
| Red Hat JBoss Application Server Process Controller | regex '(?i)\bjava(?:\.exe)?$' | regex 'org\.jboss\.as\.process-controller' |
Versioning
Version information for the product is currently collected using one of three possible methods.
The methods are tried in an order of precedence based on likely success and/or accuracy of the information that can be gathered. Once a result is obtained, the methods lower in precedence are not attempted. In order of precedence the methods are:
Active Versioning
For this active versioning technique the base installation directory for the running instance is identified; for versions of JBoss AS starting from 7.0.0 also we need to find the mode in whihc server was started from trigger process arguments. Using all this information the shell or batch file that instigated the instance is ran with a -V argument, which results in the version number being printed.
For JBoss Application Server prior to 7.x.x the Version Command results in a shell script being run in the bin directory that the main run.jar file is being run from, for newer releases of program shell or batch file name is equal to mode in which it was started.
Obtaining BASE_DIR
The first thing we do is to attempt to acquire the servers base installation directory (%base_dir%), we do this by parsing the cmd and args against a regex and store the output in the base_dir variable. Note that regular expressions are different for versions 7.x.x and older ones:
| Version | Platform | Regex |
|---|---|---|
| < 7.0.0 | UNIX | -(?:cp|classpath).*?[\s":](/\S+?)bin/run\.jar |
| < 7.0.0 | UNIX | -Djava\.endorsed\.dirs="?(?:[^:"\s]+:)*?(/[^:"\s]+?)/lib/endorsed[:"\s] |
| < 7.0.0 | UNIX | (?ix)\b(?:cp|classpath) \s "? (?:[^:"\s]*?:)*? (/[^:"\s]*jboss[^:"\s]*) /(?:bin|lib)/\w+\.jar |
| < 7.0.0 | Windows | (?i)(?:cp|classpath).*?[\s";](\w:\\.+?)\\bin\\run\.jar |
| < 7.0.0 | Windows | (?i)-Djava\.endorsed\.dirs="?(?:[^";]*?;)*?(\w:[^";]+?)\\lib\\endorsed[;"\s] |
| < 7.0.0 | Windows | (?ix)\b(?:cp|classpath) \s "? (?:[^";]*?;)* (\w:\\.*?jboss[^;"]*?) \\(?:bin|lib)\\\w+\.jar |
| ≥ 7.0.0 | UNIX | -Djboss\.home\.dir=(/\S+) |
| ≥ 7.0.0 | Windows | "-Djboss\.home\.dir=(\w:[\\/][^"]+)" |
| ≥ 7.0.0 | Windows | -Djboss\.home\.dir="(\w:[\\/][^"]+)" |
Obtaining MODE
This is needed 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 using matching:
- org.jboss.as.standalone - Mode is standalone
- org.jboss.as.server - Mode is domain
Versioning command
If we are able to acquire the base installation directory and mode if needed then we will attempt to run one of the following version commands:
- For version <7.0.0 on Windows we run the command (cd /d <base_dir> && echo "" | run -V)
- For version ≥7.0.0 on Windows we run the command (cd /d <base_dir> && echo "" | <mode> -V)
- For version <7.0.0 on UNIX we run the command (cd %base_dir%; echo "" | ./run.sh -V | grep build)
- For version ≥7.0.0 on UNIX we run the command (cd %base_dir%; echo "" | ./<mode>.sh -V | grep build)
Versioning command
The regex, JBoss\s+(\d+(?:\.\d)*), is then applied to the value of command's result and the pattern uses output as version.
This method of versioning is accurate and safe, a number of restraints have been applied to the regex to ensure it will only be run when confidence is high in the supplied data.
For older versions of JBoss the "(/.?/bin)" for UNIX or "(.?
bin)" part of the path check before run.jar ensures that the regex is only matched when we have full, explicit path, thus preventing the above command being run with a relative path.
If version command is successfully executed the line that is returned by the grep contains the JBoss Version and build number. The line returned is expected to contain the string 'JBoss' at its beginning, followed by the version of the product. If the line returned does not match these requirements, the version is not set and one of the other versioning approaches is used.
Path Versioning
All Platforms.
If the Active Version Command does not return any version information then 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 applying a regex to the commands path, in this case we apply a regex to the arguments to see if there is a version number that can be used.
| Path Regex: | (?i)\b(?:cp|classpath).*?jboss[_\-\\/\.]?(\d+(?:[_\-\.]\d+)*) |
|---|
The Regex looks for the word "jboss" somewhere in the classpath and following that a string of digits separated by either underscores, hyphens or periods - this results in a accurate version number that can catch a number of different formats without being open to erroneous inputs.
The result of this regex is 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 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
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.
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 preference way in which versioning can be achieved - as such 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 JBoss Application Server is installed then the version information may not be mapped to the correct instance that has been identified.
Alternative Versioning Approach
At the current time we do not know of any further techniques that could be used to version JBoss.
Additional information
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. Need value can be parsed using the following regular expression against trigger process's arguments:
- [/\\]domain[/\\]servers[/\\]([^\\/ ]+)[/\\]
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+)
Note that in last regex the value which is parsed more correctly should be called profile name.
Application Model Produced by Software Pattern
Product Architecture
JBoss Application Server 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 ran this script starts the Java VM and passes all the relevant variables to it to start the JBoss Application Server.
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 instances of JBoss relatively easily.
Software Pattern Model
One pattern has been created with the JBoss Application Server and JBoss Application Server (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
SI Depth
Although the pattern in general produces Deep (instance-based) Software Instance based primarily on BASE_DIR the approaches in particular are all different for older and newer versions of JBoss and for last it also depends on mode of server.
SI Depth for Standalone mode
This approach is only for JBoss AS version 7.0.0 or newer started in 'standalone' mode.
If BASE_DIR 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.0 or newer started in 'domain' mode.
If BASE_DIR and server name were successfully discovered then the key is based on them and host's key, else if only BASE_DIR was found the pattern uses key group based on it. In other cases the pattern doesn't set key letting ADDM manage found instances automatically.
SI Depth for older versions
This approach is only for JBoss AS version older than 7.0.0.
If BASE_DIR and/or server name were successfully discovered the pattern creates the key based on them (or only on BASE_DIR) and host's key, else it creates key group based on parsed from process's arguments java classpath or just those arguments.
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.
Relationship Creation
Currently there are no relationships created by the pattern as there are no known relationships between the main JBoss process and other software/processes.
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.
Information Sources
Open Issues
| TOP |
|---|
Created by: Rebecca Shalfield 26 Oct 2007
Updated by: Nikola Vukovljak 22 Mar 2012
