Project:Java/Tomcat 6 Guide

From Gentoo Wiki
Jump to:navigation Jump to:search
The information in this article is representative of former times and has been archived. It can be used for reference, but is most likely not appropriate for current usage. Generally, archived articles should not be edited.

Some aspects of Tomcat on Gentoo are slightly different than how upstream handles it. This document aims to provide some information on how it differs. This document is based on Tomcat versions 6.0.x and later. Versions of Tomcat older than 5.5.x should not be used, as it is discouraged by upstream. Otherwise please use 6.0.x or later when released.

The biggest initial difference on Gentoo is Tomcat being spread across multiple directories. That is because applications on Gentoo strive to comply FHS, in addition to Gentoo-specific standards. Another major differences is that Tomcat is compiled from source, along with the latest versions of any dependencies and bundled libraries, which will also be compiled from source. There are a number of smaller details, which will be covered in this guide.

This document will not cover Java Servlet Specifications, nor general Tomcat configuration. This document assumes the reader has a basic understanding of what a Java Web Application is, consists of, and basics of how to configure a container for the web application.

Layout

Standard Tomcat layout

The root directory of a typical Tomcat binary distribution is laid out as illustrated in the following listing:

/opt/tomcat-x.y/bin
/opt/tomcat-x.y/conf
/opt/tomcat-x.y/logs
/opt/tomcat-x.y/lib
/opt/tomcat-x.y/shared
/opt/tomcat-x.y/temp
/opt/tomcat-x.y/webapps
/opt/tomcat-x.y/work
Note
Substitute 6 for x.y if the version of Tomcat being used is in the 6.x realm.

Gentoo Tomcat layout

To comply with FHS and Gentoo standards, Tomcat has been dissected and installed into the following locations:

/usr/share/tomcat-x.y/bin
/etc/tomcat-x.y
/var/log/tomcat-x.y/logs
/usr/share/tomcat-x.y/lib
/var/lib/tomcat-x.y/shared
/var/tmp/tomcat-x.y
/var/lib/tomcat-x.y/webapps
/var/run/tomcat-x.y

Configuration files

In addition to simply moving the Tomcat /conf directory under /etc. There is a Gentoo-specific Tomcat configuration file /etc/conf.d/tomcat-x.y, which contains Tomcat variables that are sourced by /etc/init.d/tomcat-x.y. These variables are:

  • JAVA_HOME: default is to be set to $(java-config --jdk-home). Changing this variable allows Tomcat to run with a VM other than the system VM
  • CATALINA_HOME: default is /usr/share/tomcat-x.y
  • CATALINA_BASE: default is /var/lib/tomcat-x.y
  • CATALINA_USER: default is tomcat
  • CATALINA_LIBDIR: default is typically /usr/share/tomcat-x.y/lib
  • CLASSPATH: default is ${CATALINA_LIBDIR}
  • CATALINA_TMPDIR: default is /var/tmp/tomcat-x.y
  • TOMCAT_START: default is "start", with alternatives being "debug", "start -security", "debug -security", or "jpda start"
  • TOMCAT_STOP: default is "stop"
  • CATALINA_OPTS: not set by default , can be used to pass options to Java or Tomcat

The Gentoo init script is also installed into /etc, at /etc/init.d/tomcat-x.y. Tomcat on Gentoo no longer uses or modifies catalina.sh.

Web applications

The /var/lib/tomcat-x.y/ contains shared for shared libraries, webapps for web applications, and symlinks to other Tomcat directories. This directory serves as the hub and is referenced by Tomcat as the CATALINA_BASE.

Runtime files

These directories hold logs, temp, and working files used by Tomcat:

/var/tmp/tomcat-x.y
Tomcat's temporary directory
/var/run/tomcat-x.y
Tomcat's working directory, where JSPs Java sources and resulting class files live
/var/log/tomcat-x.y
Tomcat's logging directory

Installation

USE flags

Tomcat's USE flags are not any different from USE flags for any package on Gentoo. Most are self-explanatory like doc, source, and test. They are for documentation, sources, and running unit tests, correspondingly.

The examples USE flag should be used for anyone new to Tomcat, Java Web Application development, or just about anything beyond deploying existing applications. When set, the examples USE flag will install the example web applications. Most all can safely ignore this USE flag, unless you are starting out.

Emerge

Once you have the desired USE flags set in /etc/portage/make.conf or /etc/portage/package.use and added packages names to /etc/portage/package.keywords it is time to actually install Tomcat. Tomcat, like every other package on Gentoo, is installed by doing:

root #emerge --ask www-servers/tomcat
Warning
Because Tomcat is compiled from source, along with all its dependencies, a lot of packages may be pulled in at emerge time. Good news is, since it's Java, aside from download time, should compile rather quickly even on older machines.

Usage

Configuring Tomcat

Depending on what Tomcat will be used for, one may or may not need to finely configure Tomcat. If Tomcat is just a dependency of another application, one might be able to simple start Tomcat, and request the application via a browser or etc at http://127.0.0.1:8080/.

For most others, particularly developers, running more than one site under Tomcat, or etc. will need to edit Tomcat's main configuration file /etc/tomcat-x.y/server.xml. The syntax of that file, and configuration of Tomcat is beyond the scope of this document. Please refer to Tomcat documentation for more information.

Using a specific VM

By default, Tomcat will use the system VM controlled by java-config as-per the JAVA_HOME variable in /etc/conf.d/tomcat-x.y. One can change that variable to point to any VM that is capable of running Tomcat. Then, when Tomcat is started, it will use the specified VM.

Logging

As of 5.5.x Logging has changed a bit. Tomcat no longer uses log4j by default. Applications can still use log4j, however the jars have to be put onto the classpath manually. For more information please refer to Tomcat's documentation on logging. http://jakarta.apache.org/commons/logging/tech.html

Warning
log4j.jar MUST be in the same directory as commons-logging.jar. The lowest classloader level they should be put in is /usr/share/tomcat-x.y/lib. The recommended is /var/lib/tomcat-x.y/shared, or in a specific webapp's WEB-INF/lib directory.

OpenRC

Tomcat is started and stopped the same as any service on Gentoo:

root #/etc/init.d/tomcat-x.y [ start
root # stop
root # restart ]

Tomcat's standard web applications

By default we do not install Tomcat's admin, docs, or examples web application. We do, however, install Tomcat's ROOT and manager applications. However per upstream Tomcat policy, no usernames or passwords are configured by default. /etc/tomcat-x.y/tomcat-users.xml should be modified to add users:

Note
As of 6.0.x the admin webapp is no longer shipped or developed. It's not in the sources, nor available as a binary for download.

Troubleshooting

Missing Jar - tomcat-dbcp.jar

Currently the tomcat-dbcp.jar is not build by default. To build that jar Tomcat robs .java source files from 3 other commons packages, collections, pool, and dbcp. There is no clean solution to compiling this jar at this time. Suggestions, patches, or any assistance on compiling that jar is greatly appreciated.

There are alternatives to this jar. You can use commons-dbcp.jar, or use the factory provided by most all jdbc drivers.

Note
For the time being anyone who needs that jar should fetch it from a binary release of Tomcat 6.0.x. Just place the jar into /lib and you will be all set.

For more information on the missing jar, please refer to bug #144276.

Future

Possibilities for Tomcat on Gentoo

These are some features which are either in consideration, under development, or are only a dream. Ideally to be implemented in the order listed below:

  • Gentoo Web Application integration support per GLEP 11.
  • Documentation on Tomcat's connectors and using them to connect to Apache on Gentoo Linux.
  • Replace init script with one developed by a Tomcat developer: http://www.webdroid.org:8080/repo/viewcvs.cgi/tomcat-package/trunk/bin/
  • Modify Tomcat init script or ebuild to use JSVC so Tomcat can run on unprivileged ports. This might not happen, as in there are other ways to do this. We are working with upstream on this but are far from an ideal solution (see bug #75224