Discover with BMC Discovery
download

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
Tomcat
Publisher Page
Apache Foundation
Category
Application Server Software Platforms
Release
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
Windows
TomcatClusterUnix/WindowsSoftwareInstanceInstance-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.

Identification

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.

NameCommand
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'

regex'(?i)\btomcat[1-9]?\.exe$'

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

regex'(?i)\btomcat[4-9]w\.exe$'

Versioning

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
%catalina_dir%|RELEASE-NOTES
Unix File:%catalina_dir%/webapps/ROOT/RELEASE-NOTES.txt
%catalina_dir%/RELEASE-NOTES

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/catalina.sh 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:

regex:


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

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

regex:


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

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

Risks

  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="org.apache.catalina.tribes.group.GroupChannel"]/Membership/@address'
Port'//Cluster/Channel[@className="org.apache.catalina.tribes.group.GroupChannel"]/Membership/@port'

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
jmx_enabled

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

exists


jmx_port


-Dcom.sun.management.jmxremote.port=(\d+)

jmx_ssl


-Dcom\.sun\.management\.jmxremote\.ssl=(\w+)

jmx_authenticate


-Dcom\.sun\.management\.jmxremote\.authenticate=(\w+)

jmx_ssl_need_client_auth


-Dcom\.sun\.management\.jmxremote\.ssl\.need\.client\.auth=(\w+)

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

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

Was this page helpful? Yes No Submitting... Thank you
© Copyright 2019 BMC Software, Inc.