Page History

...

• Prior to Tomcat 5.5, Tomcat provided a Logger element that you could configure and extend according to your needs. If you are using a Tomcat version previous to Tomcat 5.5, make sure to read the Logger configuration reference.
• Starting with Tomcat 5.5, Logger was removed and Jakarta Apache Commons-Logging Log is used everywhere in Tomcat. Read the Commons-Logging documentation if you'd like to know how to better use and configure Tomcat's internal logging. See also http://tomcat.apache.org/tomcat-5.5-doc/logging.html
• To enable request logging similar to the Apache HTTP server, you may include the following line in the server.xml file, in the <Engine> tag:
  • <Valve className="org.apache.catalina.valves.AccessLogValve"
    • directory="logs" prefix="localhost_access_log." suffix=".log" pattern="common" resolveHosts="false"/>
  • This will produce a log file for each day, such as logs/localhost_access_log.2008-03-10.log, containing the files requested, IP address of the requester, and similar information.

    • Wiki Markup
      128.34.123.121 - - \[10/Mar/2008:15:55:57 -0500\] "GET /upload/ClickPoints.jsp HTTP/1.1" 200 2725 \\

In addition, Tomcat does not swallow the System.out and System.err JVM output streams. You may use these streams for elementary logging if you wish, but a more robust approach such as commons-logging or Log4J is recommended for production applications.

...

Tomcat wants to support multiple logging implementations, so it uses commons-logging. In case that's unclear, think of it like this. You are a Tomcat developer. The car you drive when logging is the commons-logging car. The engine of that car is either JULI or log4j. Without one of these engines, the car goes no where. However regardless of whether you use JULI or log4j, the steering wheel, break, gas pedal, etc. are the same.

Related FAQ: What role does JULI and log4j play in logging?

First see: What role does commons-logging play in logging?

Note in addition that in your own applications you could log directly with JULI or log4j. But once you choose one, you can't easily switch to the other later. If you use commons-logging you can.

...

You need to specify a commons-logging configuration file and, if you wish, a logging implementation that supports commons-logging. JDK 1.4 (and later) java.util.Logging and Log4j are the two most commonly used logging toolkits for Tomcat. Tomcat 5.5 and Tomcat 6.0 use java.logging as default implementation for commons-logging. So this should work by default, but sometimes it doesn't (see Need for it to be in bootstrap classpath?] #Q9).

If you supply an external logging toolkit such as Log4J, it needs to be located in the $CATALINA_HOME/common/lib directory (for Tomcat 5.0 and earlier). Tomcat 5.5 and later uses commons-logging while bootstrapping so some people suggest adding Log4j to the bootstrap classpath by using the scripts in $CATALINA_HOME/bin (see [http://markmail.org/message/3sgxfol3njcfutsm Need for it to be in bootstrap classpath?). A better approch approach apparently working is:

1. Put log4j.jar in the $CATALINA_HOME/common/lib directory
2. Put the full commons-logging.jar in the $CATALINA_HOME/common/lib directory, even if you see the reduced API version there, named commons-logging-api.jar
   

Through some classloading voodoo during bootstrapping, if you have the full commons-logging.jar file in your common/lib directory, it replaces the classes from the commons-logging-api.jar file and will reinitialize the logging system and attempt to locate log4j or whatever other logging system you may be using. (see this thread).

The above recipe is for Tomcat 5.5. For Tomcat 6 - see Documentation.

See also the following For more detailed instructions, see these mailing list discussions:

...

While you can use System.out and System.err to log, we strongly recommend using a toolkit like Log4J or JDK 1.4's java.util.logging package. With these toolkits, you have significantly more functionality (for . For example, sending emails, logging to a database, controlling at runtime the logging level of different classes, inspecting the logs with a graphical viewer, etc.) than with Tomcat's built-in default logging configuration.

We also recommend that you separate your logging from Tomcat's internal logging. That means you should bundle your logging toolkit with your webapp. If you 're are using Log4J, for example, place the Log4J jar in the WEB-INF/lib directory of your webapp and the Log4J configuration file in the WEB-INF/classes directory of your webapp. This way different web applications can have different logging configurations and you don't need to worry about them interfering with each other.

...

For another example of how to set this look in catalina.sh for Tomcat 6.0.16 on lines 182-185. The statements look like this: Wiki Markup\

# Set juli 

...

LogManager

...

 if it is present

...

if 

...

[ -r "$CATALINA_BASE"/conf/logging.properties 

...

]; then

...

  JAVA_OPTS="$JAVA_OPTS "-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager" "-Djava.util.logging.config.file="$CATALINA_BASE/conf/logging.properties"

...

fi

Projects such as JPackage that repackage Tomcat for Linux typically move the configuration to a directory dictated by the FHS standard (http://www.pathname.com/fhs/), and therefore use the java.util.logging.config.file property to set the location of the logging.properties file in the Tomcat startup script.

...

1. tomcat-juli.jar should be in your $CATALINA_HOME/bin directory
2. tomcat startup script should run java with -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
3. tomcat startup script should run java with -Djava.util.logging.config.file=<some_path>/logging.properties
4. obviously, the logging.properties file must exist in the directory specified in the tomcat script at point #3
   

...

• look for what Tomcat version you got installed with: yum list installed tomcat5
  

Since I had the 5.5.23, I downloaded the Tomcat Binaries 5.5.23 from http://archive.apache.org/dist/tomcat/, then:

...