Part 1 2 3 4

Tomcat Directories and How It Launches

Let’s pop into the tomcat directory and see what we have.

We’ll try to understand what’s in each of the directories listed

/bin
This directory is never used during runtime. It’s sole purpose is to store scripts and boostrap libs.  This directory contains the startup and stop scripts used to launch and kill TC as well as all the scripts it they call

/conf
This directory contains server level versions of the following files:

• context.xml
  • In TC, a context is an application deployed in TC
• tomcat-users.xml
  • Provides access control to applications running on the server
• server.xml
  • Provides all the connectors, ports, engines, virtual hosts configured in the server
• web.xml
  • Following the J2EE spec, this is the config file for the web applications defined at the top server level. It essentially tells the servlet engine what servlets map to which URIs, maps filters, security settings, etc.
• logging.properties
  • Allows you define the logging levels within the server although you’ll probably want to set this up on a per application basis. TC now uses the java.util.logging package for logging instead of the previous log4j as the former was found to be a source of memory leaks on hot swaps
• context.xml
  • A place to provide <Context> snippets. Usually, each application will contain one of these in the META-INF folder so you can control context settings at the application level
• catalina.policy
  • The JVM uses this for security decisions and only if you invoke TC with the –security option
• catalina.properties file
  • • A regular Java properties file sued to set class loader paths, security package lists, and some tunable parameters. One useful feature of it is the ability to set properties that can be referenced in other files.
      EG: # Some Setting
      some.setting=1234
      And in another file such as server.xml
      <Connector port=”${some.setting}”

NOTE: another great feature of TC is that all of these files can exist on a per application basis as well.

/lib
Contains the jars necessary to launch TC. The bootstrap process looks in CATALINA_HOME/lib directory for these jars

/logs
Well, you can only imagine!

/temp
This directory is used by the JVM for temporary files. (java.io.tmpdir)

/work
This is a server level working directory for web applications

/webapps
This is where you place your applications that run within TC.

Understanding the TC Launch Procedure

Typical startup procedure for TC on EC2 machine goes something like this (assuming you’re using bash)

./usr/local/tomcat/bin/startup.sh

By default, this should launch TC on the machine at port 8080. But before you run off and do this, let’s examine the sequence of events that take place when you run this command, the actions that are performed during this launch, and ways to simplify your life in the process.

• startup.sh
  The sole purpose of this file is to locate and call catalina.sh with the start option.
• catalina.sh
  Well, this file does quite a bit. But, the important parts are
  • Invokes the setclasspath.sh script
  • Invokes the setenv.sh script if it exists
  • Launches the JVM (if the JVM is located)
• setclasspath.sh
  TC is a Java application. In order to run, it needs Java installed on the system. This script if responsible for finding the JVM and making sure it’s on the classpath to run and setting up some variables for use by the JVM. The JVM is found by examining the system classpath for the JAVA_HOME variable.  Many tutorials on this subject will tell you make sure you set the JAVA_HOME var in your ~/.bashrc file or even in the startup.sh script. Although these are acceptable, they aren’t the most extensible and flexible approach to use. Which leads us to……
• setenv.sh
  The catalina.sh script looks to see if there’s a setenv.sh file in CATALINA_BASE/bin. If it’s there, it’s executed prior to launching the JVM. This is the perfect place to put all of your environment settings specific to a TC instance.
  Further along, we’ll examine how to set up TC instances in a way that allows you to control and isolate your deployments. The setenv.sh file is a great place to store things like your JAVA_HOME variable. This allows you to switch between, let’s say, 1.5 and 1.6 and if you find there are issues in the latter, you simple switch back as needed.

  The setenv.sh file doesn’t exist in the basic install. Simple create one and put all of your environment setting export lines in it. When it’s time to upgrade TC, simply copy it over. Quite slick!

Tweet This Post