Page tree
Skip to end of metadata
Go to start of metadata
Product Name
Publisher Page
Apache Foundation
Application Server Software Platforms
TKU 2021-Mar-1
More Information
Publisher Link
Apache Foundation

Product Description

Extended Discovery pattern which models Apache Tomcat web applications is available for this product.

Apache Tomcat is an Application Server, otherwise known as a Web Container, developed at the Apache Software Foundation (ASF).

Tomcat implements the Java Servlet and the JavaServer Pages (JSP) specifications from Sun Microsystems, providing an environment for Java code to run in cooperation with a web server, in addition it adds tools for configuration and management, which can also be configured by editing configuration files that are normally XML-formatted, and includes its own internal HTTP server.

Pattern also identifies the Pivotal tc Server, that contains all of vanilla Tomcat, Pivotal tc Server also has a few optional extensions designed to make it easier to deploy and maintain.

Software Pattern Summary

Product ComponentOS TypeVersioningPattern Depth
TomcatUnixActive, Path, PackageInstance-based

Platforms Supported by the Pattern

The current pattern identifies an instance of Apache Tomcat Application Server or Pivotal tc Server running on both Unix/Linux and Microsoft Windows platforms.


Software Instance Triggers

The pattern usually triggers on a java, jsvc or jsvc.exec process with "org.apache.catalina.startup.(?:Bootstrap|Tomcat|Main)" in the arguments. Rarely it also triggers on a tomcat[^ \\]*?.exe process, a jk_nt_service.exe process or, for some embedded systems, binary could have custom process name, but it must have "//RS//" (Run Service) in it's arguments.

The pattern will stop immediately if it encounters '-Dcom.sun.web.console.base' in the trigger process command line arguments indicating it has triggers off the Tomcat component within Sun Java Web Console.

Software Instance type attributes created

The patterns in this module will set the following value for the type attribute on a SI:

 Pattern NameSI type
TomcatApache Tomcat Application Server

Other Node types created

The patterns will also create the following additional nodes:

 Pattern NameNodeNode typeDiscovery/ADDM Version
TomcatClusterSoftwareClusterApache Tomcat Application Server ClusterBMC Discovery 11.0 and after

Simple Identification Mappings

The following components or processes are identified using the combination of pattern definitions and simple identity mappings which map other known (but deemed less important in terms of application modeling) processes. For further details on the processes treated as primes, see paragraph 748418082.

Apache Tomcat Servlet Engine

regex '^.*org\.apache\.catalina\.startup\.Bootstrap'

regex '^.*org\.apache\.tomcat\.startup\.Tomcat'

regex '^.*org\.apache\.tomcat\.startup\.Main'


regex'(^|/)jsvc', regex '^.*org\.apache\.catalina\.startup\.Bootstrap'


regex'(^|/)jsvc', regex '^.*org\.apache\.tomcat\.startup\.Tomcat'


regex'(^|/)jsvc', regex '^.*org\.apache\.tomcat\.startup\.Main'


Jakarta NT Service Wrapper for Tomcatregex'(?i)\bjk_nt_service\.exe$'
Apache Tomcat Service Manager (Windows)



Version information for the product is currently collected using one of three possible methods. We execute the methods in order based on their accuracy, depth and reliability.

Common Functionality

In order to obtain all the needed attribute values by parsing the Java process arguments, full paths should be used for environment variables in Apache Tomcat startup scripts.

Obtaining the arguments

The first step for both active versioning techniques is an identification of the base installation directory. This is obtained by parsing the JAVA arguments. On UNIX these arguments can be obtained by looking at the trigger process arguments.

For Windows the method of obtaining the arguments is more complicated and initially the pattern will obtain the root directory of the trigger process.
This is obtained by applying the following regular expression of the trigger process command-line:

  • (?i)(^\w:.+)\\bin\\tomcat[^ \\]*?\.exe$

If this fails, the pattern searches for the related Windows service and parses the cmdline attribute using the following regular expression:

  • (?i)^"?(\w:\\.*)\\bin\\tomcat[^ \\]*?\.exe

Furthermore on Windows, the arguments of the Tomcat process are not included in the trigger process and must be obtained from the registry.
As there may be more than one installation, the pattern looks in the registry for all sub directories of:

  • .HKEY_LOCAL_MACHINE\\SOFTWARE\\Apache Software Foundation\\Procrun 2.0

If it can find a registry key of the form:

  • HKEY_LOCAL_MACHINE\\SOFTWARE\\Apache Software Foundation\\Procrun 2.0\\<directory name>\\Paramaters\\Log\\Path

and the path parsed using the regular expression:

  • (?i)(^\w\:.+)\\logs

matches the root directory, then the pattern will take the java arguments to be in the following registry key:

  • HKEY_LOCAL_MACHINE\\SOFTWARE\\Apache Software Foundation\\Procrun 2.0\\<directory name>\\Paramaters\\Java\\Options
    HKEY_LOCAL_MACHINE\\SOFTWARE\\Apache Software Foundation\\Procrun 2.0\\<directory name>\\Paramaters\\Java\\Classpath
    HKEY_LOCAL_MACHINE\\SOFTWARE\\Apache Software Foundation\\Procrun 2.0\\<directory name>\\Paramaters\\Java\\Jvm

File Versioning

The file version method attempts to access the release notes of the identified Tomcat process.

If we have been able to extract the catalina_home directory from the process' arguments, then we use the value found in the argument as the base directory.

If catalina_home was not obtained, the pattern will use catalina_base as the base directory. From there the pattern attempts to open the RELEASE-NOTES.txt (or RELEASE-NOTES) file.


Once opened the file contents are parsed against a regular expression to extract the version information.

  • (?i)Apache Tomcat Version\s+(\d(?:\.\d+)*)

We have found that this approach provides a version number up to 4 levels of depth.

Active Versioning

This is attempted on UNIX only.

The pattern attempts to run the following command:

If the command returns no helpful result, but the path to the java process is absolute, the pattern will extract the installation directory using the following regular expression:

  • ^(/.+)/bin/java$

Alternatively, the java installation directory will be obtained by executing and parsing the result of the following command:

  • env | grep JAVA_HOME

If the java installation directory was obtained, the pattern will run the following commands:

  • JAVA_HOME="<java_install_dir>" <catalina home>/bin/ version
  • <java_home>/bin/java -cp <catalina_home>/lib/catalina.jar org.apache.catalina.util.ServerInfo

The version is obtained by parsing the output with one of the following regular expressions:

  • Server number:\s*(\d+(?:\.\d+)*)
  • [vV]ersion:\s*Apache Tomcat/(\d+(?:\.\d+)*)

This approach usually returns a version between 3 to 4 levels of depth.

Path Versioning

If the pattern is unable to acquire the version by using an active versioning method, it will attempt to parse the process's command line.

First the pattern concatenates the process's command into a single value. This allows it to achieve a greater level of success as the process cmd may not contain a path.

The following regular expression is then applied to this path:

  • (?i)tomcat[-/_ ]?(\d(?:[\-\.]\d+)+)

If the version is not obtained, an alternative regular expression is tried:

  • (?i)tomcat(\d(?:[\-\.]\d+)*)

Path versioning usually returns a version between 2 to 4 levels of depth. If the pattern acquires a version from the path it is normalized, it ensures that all versions are returned in a common format.

Package Versioning

If the pattern is unable to extract the version information from either the Active Command or Path regex, then it will attempt to query the package management system to identify a specific version.

The package query uses a set of regular expressions to be checked for.

Regex List

  • (?i)tomcat$
  • (?i)tomcat\d+$

This usually returns a version between 3 to 4 levels of depth.

Though this method is often successful it is no specific to an installation, and this may result in the version information for a Tomcat installation being inaccurate if there are multiple installations on the host.

Alternative Versioning Approach

Registry Versioning

From version 5.0 onwards Apache Tomcat on Windows has had information stored in the Registry. We have identified the following registry keys that returns the information:
Registry Keys

  • HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat\5.0\Version
  • HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat\5.5\version
  • HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat\6.0\version


  1. Product version obtained by reading the registry is only used if no other method succeeds. i.e. if a matcher implements multiple versioning methods, and more than one succeeds, Registry versioning has the lowest precedence and may therefore be ignored.
  2. Product version can be obtained through Registry only for Tomcat 5.0 and above - thus, if path regex versioning is completely replaced with Registry-based method, while depth of versions obtained is likely to increase, the overall coverage may decrease.
  3. Tomcat is often bundled with other applications. This may lead to more than one instance of Tomcat being installed and running on a host. At present, there is no way to directly link the detected process with a value obtained from the Registry. This may lead to false positives.

It is our conclusion that this versioning approach could be used but only once an understanding of the customer environment exists and where the risks listed above have been evaluated and found to be low.

Due to these risks we have not included it in the versioning techniques in the pattern. In the future it would be a consideration.

SoftwareInstance versioning

TomcatCluster pattern uses SoftwareInstance versioning meaning it takes the version from the Apache Tomcat instances it had triggered off.

Future Considerations

An additional Windows versioning technique that can be used is the Registry query. Once we are able to execute this query in a more controlled manner, then it weill be added to the pattern.

Additional Attributes

Catalina Base and Catalina Home

The pattern first tries to obtain catalina_base and catalina_home from the relevant arguments (-Dcatalina.base and -Dcatalina.home) in the trigger process.

If that fails, it assumes that catalina_base and catalina_home are the same as the path to the triggering tomcat.exe process.

If that fails, it obtains catalina_home from the EM_HOME argument in the trigger process. If -DEM_HOME points to /opt/foo then both catalina_home and catalina_base are referred to /opt/foo/etc/emweb

Listening Ports

We obtain listening_ports from the <catalina_base>/conf/server.xml file. We part the file with these xpaths:

  • /Server/@port
  • /Server/Service/Connector/@port

We also check for port information in the argument of the triggered process.

Application Model Produced by Software Pattern

Product Architecture

Tomcat Application server is a container for other application to be run in. It allows the running of J2EE applications in a controlled web based environment.

As such, it sits on top of a web server and processes requests from the user to the Java application that is being hosted. From an external view there is no visibility of what application Tomcat is hosting, where this application resides or what its purpose is, all you see is that Tomcat running on a host.

There is no indication that this product branches, has multiple threads or creates any child processes.

Tomcat Cluster architecture

Tomcat Cluster is modeled by BMC Discovery from v11.0 onward.

Tomcat Cluster doesn't do Application replication between the member nodes. Session replication and load balancing may be achieved by using external tools only.

The cluster configuration is stored in server.xml file of Tomcat instance. There multicast IP address and port are mentioned. This cluster socket is used as cluster ID by ADDM. All members list can't be obtained unfortunately, therefore the cluster scale is always unknown.

Tomcat pattern deploys the following xpath expressions to extract cluster_multicast_socket atribute:

Attributexpath expression
IP address'//Cluster/Channel[@className=""]/Membership/@address'

The combination of <IP address>:<Port> is used as a cluster ID by TomcatCluster pattern. The cluster key is combined of a cluster ID and si_type. This pattern also sets Containment link with all Tomcat instances which have the same cluster_multicast_socket attribute.

Tomcat cluster BMC Discovery model

On the following diagram Apache Tomcat Cluster SoftwareCluster instance is displayed:

Tomcat Cluster visualization

JMX attributes

Various JMX attributes are obtained by the pattern. This is only attempted for Atrium Discovery version 8.1 and above. The attributes are obtained by parsing the 748418082 using the following regular expressions:

AttributeRegular expression

True if




Software Pattern Model

The pattern is triggered on any of the many forms that Tomcat can be run in, either on one of the specific binaries or java/class combinations. Once triggered we are sure that the process is a valid running Tomcat installation.

If the following argument is present in the process arguments:

  • com.springsource.tcserver

an instance of Pivotal tc Server is created.

SI Depth

If catalina base has been discovered, an instance based Software Instance is created with a key based on catalina base, type and host key.

If catalina home has been discovered (and catalina_base hasn't), a grouped Software Instance is created with a key based on catalina home, type and host key.

In all other cases a grouped Software Instance is created with key based on trigger process, JAVA classpath, type and host key.

Subject Matter Expertise

We have received SME input with regards the 748418082 technique. It identified the Release Notes text file containing version information in the installation directory of the product.

Any further SME input would be welcome on any other potential approaches to improve Tomcat versioning coverage and depth, or with regards identifying the applications running on a particular installation.


Testing to ensure that the processes related to Apache Tomcat Server have been correctly identified are performed using record data as well as live discovery of hosts running Solaris, Linux and Windows operating systems.

Both live discovery and record data contained enough data to extract the version information using the path regular expression methods.

Information Sources

Tomcat Wikipedia was used to gather information on the product and produced a lot of the product description. It was also used as the source for some of our known versions.

The official Apache Tomcat homepage was used to identify some versioning techniques and completed the information we had on known versions.

Open Issues

There are no outstanding issues with this pattern.