Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change 
notification.
The "FAQ/Logging" page has been changed by ChrisTrevarthen.
http://wiki.apache.org/tomcat/FAQ/Logging?action=diff&rev1=14&rev2=15

--------------------------------------------------

   1. [[#Q9|Since java.logging is the default commons-logging implementation in 
Tomcat, why is it not working in my Linux distribution?]]
  
  == Answers ==
- 
  <<Anchor(Q1)>>'''Does Tomcat have built-in logging capabilities, and if so 
how do I use them?'''
  
  The Servlet Specification requires Servlet Containers like Tomcat to provide 
at least a rudimentary implementation of the {{{ServletContext#log}}} method. 
Tomcat provides a much richer implementation than required by the Spec, as 
follows:
  
   * 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 
[[http://tomcat.apache.org/tomcat-4.1-doc/config/logger.html|Logger 
configuration reference]].
-  * Starting with Tomcat 5.5, Logger was removed and 
[[http://jakarta.apache.org/commons/logging|Jakarta 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]]
+  * Starting with Tomcat 5.5, Logger was removed and 
[[http://jakarta.apache.org/commons/logging|Jakarta 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"
+   . <Valve className="org.apache.catalina.valves.AccessLogValve"
-                      directory="logs"  prefix="localhost_access_log." 
suffix=".log"
+    . directory="logs"  prefix="localhost_access_log." suffix=".log"
-                      pattern="common" resolveHosts="false"/>
+    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.
+   . 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.
-     128.34.123.121 - - [10/Mar/2008:15:55:57 -0500] "GET 
/upload/ClickPoints.jsp HTTP/1.1" 200 2725
+    . 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 
[[http://logging.apache.org/log4j|Log4J]] is recommended for production 
applications.
  
- 
- 
  <<Anchor(Q2)>>'''What role does commons-logging play in logging?'''
  
+ 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.
- 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?
+ Related FAQ: What role does JULI and log4j play in logging?
  
  <<Anchor(Q3)>>'''What role does JULI and log4j play in logging?'''
  
- First see:
- What role does commons-logging 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.
- 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.
  
  <<Anchor(Q4)>>'''How do I configure commons-logging for use with Tomcat?'''
  
+ 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 [[#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 apparently working is:
+ 
- 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 [[#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 apparently working is:
-   1. Put jog4j.jar in the $CATALINA_HOME/common/lib directory
+  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
+  1. 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 
[[http://markmail.org/message/3sgxfol3njcfutsm#query:+page:1+mid:7oce37bngiq2otlu+state:results|this
 thread]]).
  
@@ -81, +68 @@

  
  <<Anchor(Q6)>>'''Where does System.out go? How do I rotate catalina.out?'''
  
- System.out and System.err both print to catalina.out. But you can suppress 
this via the swallowOutput property and sent to different log files.
- catalina.out does not rotate. But it should not be an issue because nothing 
should be printing to standard output since you are using a logging package, 
right? [[http://marc.theaimsgroup.com/?t=105544472600001&r=1&w=2a|thread about 
rotation of catalina.out]]
+ System.out and System.err both print to catalina.out. But you can suppress 
this via the swallowOutput property and sent to different log files. 
catalina.out does not rotate. But it should not be an issue because nothing 
should be printing to standard output since you are using a logging package, 
right? [[http://marc.theaimsgroup.com/?t=105544472600001&r=1&w=2a|thread about 
rotation of catalina.out]]
  
  <<Anchor(Q7)>>'''Where are the logs when running Tomcat as a Windows 
service?'''
  
@@ -96, +82 @@

  
  java.util.logging.config.file
  
- Example:
- -Djava.util.logging.config.file=/etc/tomcat/logging.properties
+ Example: -Djava.util.logging.config.file=/etc/tomcat/logging.properties
  
+ 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:
- 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:
  
- # Set juli LogManager if it is present
- if [ -r "$CATALINA_BASE"/conf/logging.properties ]; then
+ # 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"
+  . 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.
- 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.
  
- On Fedora the startup script in typically located in /etc/rc.d/init.d/ and on
- Gentoo linux it is located in /etc/init.d/. On RedHat the startup script for 
Tomcat 5.5 is /etc/init.d/tomcat5 but eventually the real startup script is 
/usr/bin/dtomcat5.
+ On Fedora the startup script in typically located in /etc/rc.d/init.d/ and on 
Gentoo linux it is located in /etc/init.d/. On RedHat the startup script for 
Tomcat 5.5 is /etc/init.d/tomcat5 but eventually the real startup script is 
/usr/bin/dtomcat5.
  
  <<Anchor(Q9)>>'''Since java.logging is the default commons-logging 
implementation in Tomcat, why is it not working in my Linux distribution?'''
  
  Yes, if you read Tomcat logging documentation, it says java.util.logging 
should work by default. But many Linux distribution repackage Tomcat and 
sometimes it does NOT work by default.
  
  Here are some things you can check:
+ 
   1. tomcat-juli.jar should be in your $CATALINA_HOME/bin directory
   1. tomcat startup script should run java with 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
   1. tomcat startup script should run java with 
-Djava.util.logging.config.file=''<some_path>''/logging.properties
@@ -129, +110 @@

  If you don't know where to look for your Tomcat startup script, see the 
previous [[#Q8|How do I customize the location of the tomcat logging.properties 
file?]]
  
  In RHEL5 (RedHat Enterprise Server 5) the Tomcat 5.5 rpm installation does 
not include the tomcat-juli.jar file. This is what I made:
+ 
   * 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:
+ 
   * tar xf apache-tomcat-5.5.23.tar.gz
   * cd apache-tomcat-5.5.23/bin
   * cp tomcat-juli.jar /usr/share/tomcat5/bin/
+ 
  Restart Tomcat... and it's working!
  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to