Page tree
    Skip to end of metadata
    Go to start of metadata
    Discover with BMC Discovery

    This product can be discovered by any edition of BMC Discovery. 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 Discovery gathers about a product and how it is obtained.
    Product Name
    Publisher Page
    Apache Foundation
    Application Server Software Platforms
    TKU 2019-May-1
    Change History
    Apache Foundation Tomcat - Change History
    Reports & Attributes
    Apache Foundation Tomcat - Reports & Attributes
    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.

    Known Versions

    • 3.2
    • 3.3
    • 4.1
    • 5.0
    • 5.5
    • 6.0
    • 7.0

    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. Or rare occasions 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/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 Section Apache Tomcat#Application Model Produced by Software Pattern.

    Apache Tomcat Servlet Engine

    regex'\bjava([w]?\.exe)?$', regex '^.*org\.apache\.catalina\.startup\.Bootstrap'

    regex'\bjava([w]?\.exe)?$', regex '^.*org\.apache\.tomcat\.startup\.Tomcat'

    regex'\bjava([w]?\.exe)?$', regex '^.*org\.apache\.tomcat\.startup\.Main'

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

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

    regex'(^|/)jsvc', 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 parcing 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 to try to identify 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

    Parsing the arguments

    The pattern attempts to obtain the following attributes from the JAVA arguments

    • Catalina_base, using regular expression: (?i)\-Dcatalina\.base="?(.+?)"?\s+"?-D

    • Catalina_home, using regular expressions: (?i)\-Dcatalina\.home="?(.+?)"?\s+"?-D

      , (?i)\-Dcatalina\.home=(\w:.+\\Tomcat \d+\.\d+)

    • Classpath, using regular expression: (?i)\s(?:-classpath|-cp) \"(.+?)\"\s

    • Alternative classpath regular expression: (?i)\s(?:-classpath|-cp) ([^ ]+)

    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.

    Windows File:%catalina_dir%\webapps\ROOT\RELEASE-NOTES.txt
    Unix File:%catalina_dir%/webapps/ROOT/RELEASE-NOTES.txt

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

    File Regex:

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

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

    Active Versioning

    This is attempted on UNIX only

    The pattern attempts to run the 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

    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:



    If the pattern acquires a version from the path it is normalised it to ensure that all versions are returned in a common format.

    Path versioning usually returns a version between 2 to 4 levels of depth.

    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 we will add it to the pattern.

    Application Model Produced by Software Pattern

    Product Architecture

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

    As such it sits on top of a webserver 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 Tomcat running on a host.

    There is no indication that this product forks, 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 cluster ID by TomcatCluster pattern. The cluster key is combined of 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 shown:

    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 JAVA arguments using the following regular expressions:

    AttributeRegular expression

    True iff -Dcom\.sun\.management\.jmxremote









    Software Pattern Model

    The pattern triggers 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 Apache Tomcat#Active Versioning 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 improving Tomcat versioning coverage and depth or with regards identifying the applications running on a particular installation.


    Testing to ensure the processes related to Apache Tomcat Server have been correctly identified has been 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 information 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.

    Created by: Chris Blake 08 Feb 2010
    Updated by: Nikola Vukovljak 21 Jan 2014