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.
|Product Component||OS Type||Versioning||Pattern Depth|
|Tomcat||Unix||Active, Path, Package||Instance-based|
The current pattern identifies an instance of Apache Tomcat Application Server or Pivotal tc Server running on both Unix/Linux and Microsoft Windows platforms.
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.
The patterns in this module will set the following value for the type attribute on a SI:
|Pattern Name||SI type|
|Tomcat||Apache Tomcat Application Server|
The patterns will also create the following additional nodes:
|Pattern Name||Node||Node type||Discovery/ADDM Version|
|TomcatCluster||SoftwareCluster||Apache Tomcat Application Server Cluster||BMC Discovery 11.0 and after|
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'(^|/)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 Tomcat||regex'(?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.
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.
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:
If this fails, the pattern searches for the related Windows service and parses the cmdline attribute using the following regular expression:
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:
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:
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
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.
We have found that this approach provides a version number up to 4 levels of depth.
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:
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:
The version is obtained by parsing the output with one of the following regular expressions:
This approach usually returns a version between 3 to 4 levels of depth.
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:
If the version is not obtained, an alternative regular expression is tried:
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.
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.
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.
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:
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.
TomcatCluster pattern uses SoftwareInstance versioning meaning it takes the version from the Apache Tomcat instances it had triggered off.
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.
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
We obtain listening_ports from the <catalina_base>/conf/server.xml file. We part the file with these xpaths:
We also check for port information in the -Dcom.sun.management.jmxremote.port argument of the triggered process.
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 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:
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.
On the following diagram Apache Tomcat Cluster SoftwareCluster instance is displayed:
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:
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:
an instance of Pivotal tc Server is created.
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.
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.
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.
There are no outstanding issues with this pattern.