commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rsi...@apache.org
Subject cvs commit: jakarta-commons/logging usersguide.html
Date Mon, 22 Jul 2002 20:41:12 GMT
rsitze      2002/07/22 13:41:12

  Added:       logging  usersguide.html
  Log:
  Users guide, including best-practices notes (from my point of view).  Not everyone agrees
  with me on all the details, so feel free to raise issues/add your own ideas, etc.  If we
have
  conflicting ideas, that's probably OK as long as the pros/cons are presented along with
  differing opinions.
  
  Revision  Changes    Path
  1.1                  jakarta-commons/logging/usersguide.html
  
  Index: usersguide.html
  ===================================================================
  <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
  <html>
  <head>
     <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
     <title>Jakarta Commons Logging Users Guide</title>
  <!-- saved from url=(0022)http://internet.e-mail -->
  <style type="text/css">
  <!--
  .example { background:#ccccff }
  .xml { background:#eeeeee }
  body {  font-family: Verdana, Arial, Helvetica, sans-serif; margin-left: 40px}
  h2 {  text-decoration: underline; background-color: #DCE1FF; background-position: left;
margin-left: -30px}
  h3 {  margin-left: -10px}
  h1 {  margin-left: -30px}
  -->
  </style>
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
  
  <h1>
  Users Guide : Jakarta Commons Logging</h1>
  <i>1.0 Version</i>
  <h3>
  Table of Contents</h3>
  <a href="#Introduction">Introduction</a>
  <br><a href="#Developers">Developers</a>
  <br>&nbsp; <a href="#Best Practices">Best Practices</a>
  <br><a href="#Integration">Integration</a>
  <br>&nbsp; <a href="#Mechanism">Mechanism</a>
  <br>&nbsp; <a href="#Configuring the Logger Implementation">Configuring
the Logger Implementation</a>
  
  <h2>
  <a NAME="Introduction"></a>Introduction</h2>
  
  <p>The Jakarta Commons Logging (JCL) provides a Log interface that
  is intended to be both light-weight and independent of numerous logging toolkits.
  It provides the middleware/tooling developer a simple
  logging abstraction, that allows the user (application developer) to plug in
  a specific logging implementation.
  </p>
  
  <p>Familiarity with high-level details of various Logging implementations is presumed.
  </p>
  
  <p>The Jakarta Commons Logging provides a Log interface with thin-wrapper implementations
for
  other logging tools, including
  <a href="http://jakarta.apache.org/log4j/docs/index.html">Log4J</a>,
  <a href="http://jakarta.apache.org/avalon/logkit/index.html">Avalon LogKit</a>,
  and
  <a>JDK 1.4</a>.
  The interface maps closely to Log4J and LogKit.
  </p>
  
  <h2><a NAME="Developers"></a>Developers</h2>
  
  <p>
  To use the JCL SPI from a Java class,
  include the following import statements:
  <ul>
  <code>
  import org.apache.commons.logging.Log;
  <br>
  import org.apache.commons.logging.LogFactory;
  <br>&nbsp;
  </code>
  </ul>
  Note that some components using commons-logging may 
  either extend Log,
  or provide a component-specific LogFactory implementation.
  Review the component documentation for guidelines
  on how commons-logging should be used in such components.
  </p>
  
  <p>
  For each class definition, declare and initialize a
  <code>log</code> attribute as follows:
  <ul>
  <code>
  public class CLASS
  <br>{
  <br>&nbsp;&nbsp;&nbsp;private static Log log = LogFactory.getLog(CLASS.class);
  <br>&nbsp;&nbsp;&nbsp;...
  <br>&nbsp;
  </code>
  </ul>
  <p>
  Messages are logged to a <i>logger</i>, such as <code>log</code>
  by invoking a method corresponding to <i>priority</i>.
  The <code>org.apache.commons.logging.Log</code> interface defines the
  following methods for use
  in writing log/trace messages to the log:
  <ul>
  <code>
  <br>log.fatal(Object message);
  <br>log.fatal(Object message, Throwable t);
  <br>log.error(Object message);
  <br>log.error(Object message, Throwable t);
  <br>log.warn(Object message);
  <br>log.warn(Object message, Throwable t);
  <br>log.info(Object message);
  <br>log.info(Object message, Throwable t);
  <br>log.debug(Object message);
  <br>log.debug(Object message, Throwable t);
  <br>log.trace(Object message);
  <br>log.trace(Object message, Throwable t);
  </code>
  </ul>
  <p>
  Semantics for these methods are such that it is expected
  that the severity, from highest to lowest, of messages is ordered as above.
  </p>
  
  <p>
  In addition to the logging methods, the following are provided for code guards:
  </p>
  <ul>
  <code>
  log.isFatalEnabled();
  <br>log.isErrorEnabled();
  <br>log.isWarnEnabled();
  <br>log.isInfoEnabled();
  <br>log.isDebugEnabled();
  <br>log.isTraceEnabled();
  </code>
  </ul>
  
  
  <h3><a NAME="Best Practices">Best Practices</a></h3>
  <p>Best practices for programming/planning are presented in two categories: General
and Enterprise.
  The general principles are fairly clear.  Enterprise practices are a bit more involved
  and it is not always as clear as to why they are important.
  </p>
  <p>
  Enterprise best-practice principles apply to middleware components
  and tooling that is expected to execute in an "Enterprise" level
  environment.
  These issues relate to Logging as Internationalization,
  and fault detection.
  Enterprise requires more effort and planning, but are strongly encouraged (if not required)
  in production level systems.  Different corporate enterprises/environments have different
  requirements, so being flexible always helps.
  </p>
  
  <h4>General - Code Guards</h4>
  <p>
  Code guards are typically used to guard code that
  only needs to execute in support of logging,
  that otherwise introduces undesirable runtime overhead
  in the general case (logging disabled).
  Examples are multiple parameters, or expressions (i.e. string + " more") for parameters.
  Use the guard methods of the form <code>log.is&lt;<i>Priority</i>>()</code>
to verify
  that logging should be performed, before incurring the overhead of the logging method call.
  Yes, the logging methods will perform the same check, but only after resolving parameters.
  </p>
  
  <h4>General - Message Priorities</h4>
  It is important to ensure that log message are
  appropriate in content and severity.
  The following guidelines are strongly suggested:
  <ul>
  <li><b>fatal</b> - Severe errors that cause premature termination.
  Expect these to be immediately visible on a console,
  and MUST be internationalized.</li>
  <br>&nbsp;
  <li><b>error</b> - Other runtime errors or unexpected conditions.
  Expect these to be immediately visible on a console,
  and MUST be internationalized.</li>
  <br>&nbsp;
  <li><b>warn</b> - Use of deprecated APIs, poor use of API, 'almost' errors,
other
  runtime situations that are undesirable or unexpected, but not
  necessarily "wrong".
  Expect these to be immediately visible on a console,
  and MUST be internationalized.</li>
  <br>&nbsp;
  <li><b>info</b> - Interesting runtime events (startup/shutdown).
  Expect these to be immediately visible on a console,
  so be conservative and keep to a minimum.
  These MUST be internationalized.</li>
  <br>&nbsp;
  <li><b>debug</b> - detailed information on flow of through the system.
  Expect these to be written to logs only.
  These NEED NOT be internationalized, but it never hurts...</li>
  <br>&nbsp;
  <li><b>trace</b> - more detailed information.
  Expect these to be written to logs only.
  These NEED NOT be internationalized, but it never hurts...</li>
  </ul>
  
  <h4>Enterprise - Logging Exceptions</h4>
  The general rule in dealing with exceptions is to assume that
  the user (developer using a tooling/middleware API) isn't going
  to follow the rules.
  Since any problems that result are going to be assigned to you,
  it's in your best interest to be prepared with the proactive
  tools necessary to demonstrate that your component works correctly,
  or at worst that the problem analyzed from your logs.
  For this discussion, we must make a distinction between different types of exceptions
  based on what kind of boundries they cross:
  <ul>
  <li><p><b>External Boundries - Expected Exceptions</b>.
  This classification includes exceptions such as <code>FileNotFoundException</code>
  that cross API/SPI boundries, and are exposed to the user of a component/toolkit.
  These are listed in the 'throws' clause of a method signature.
  </p>
  <p>These exceptions should be caught immediatly prior to crossing
  the API/SPI interface back to user code-space,
  logged with full stack trace at <b>info</b> level,
  and rethrown.
  The assures that the log contains a record of the root cause for
  future analysis <i>in the event that the exception is not caught and resolved
  as expected by the user's code</i>.
  </p>
  </li>
  <li><p><b>External Boundries - Unexpected Exceptions</b>.
  This classification includes exceptions such as <code>NullPointerException</code>
  that cross API/SPI boundries, and are exposed to the user of a component/toolkit.
  These are runtime exceptions/error that are NOT
  listed in the 'throws' clause of a method signature.
  </p>
  <p>These exceptions should be caught immediatly prior to crossing
  the API/SPI interface back to user code-space,
  logged with full stack trace at <b>info</b> level,
  and rethrown/wrapped as <code><i>Component</i>InternalError</code>.
  The assures that the log contains a record of the root cause for
  future analysis <i>in the event that the exception is not caught and
  logged/reported as expected by the user's code</i>.
  </p></li>
  <li><p><b>Internal Boundries</b>.
  Exceptions that occur internally and are resolved internally.
  These should be logged when caught as <b>debug</b> or <b>info</b>
messages,
  at your discretion.
  </p></li>
  <li><p><b>Significant Internal Boundries</b>.
  Exceptions that cross over significant internal component boundries, such as networks.
  These should be logged when caught as <b>info</b> messages.
  Do not assume that such a (network) boundry will deliver exceptions to the 'other side'.
  </p></li>
  </ul>
  
  <h5>Why info level instead of debug?</h5>
  You want to have exception/problem information available for
  first-pass problem determination in a production level
  enterprise application without turning on <b>debug</b>
  as a default log level.  There is simply too much information
  in <b>debug</b> to be appropriate for day-to-day operations.
  
  <h5>More Control of Enterprise Exception Logging</h5>
  <p>If more control is desired for the level of detail of these
  'enterprise' exceptions, then consider creating a special
  logger just for these exceptions:
  <ul>
  <code>
  &nbsp;&nbsp;&nbsp;Log log = LogFactory.getLog("org.apache.<i>component</i>.enterprise");
  </code>
  </ul>
  This allows the 'enterprise' level information to be turned on/off explicitly
  by most logger implementations.
  
  </p>
  
  <h4>Enterprise - National Language Support - Internationalization</h4>
  <p>NLS internationalization involves looking up messages from
  a message file by a message key, and using that message logging.
  There are various tools in Java, and provided by other components,
  for working with NLS messages.
  </p>
  
  <p>NLS internationalization SHOULD be used for
  <b>fatal</b>, <b>error</b>, <b>warn</b>, and <b>info</b>
messages.
  It can be considered optional for <b>debug</b> and <b>trace</b>
messages.
  </p>
  
  <p>Perhaps a more direct support for internationalizing log messages
  can be introduced in a future or alternate version of the <code>Log</code> interface.
  </p>
  
  <h2><a NAME="Integration"></a>Integration</h2>
  
  <p>The minimum requirement to integrate with another logger
  is to provide an implementation of the
  <code>org.apache.commons.logging.Log</code> interface.
  In addition, an implementation of the
  <code>org.apache.commons.logging.LogFactory</code> interface
  can be provided to meet
  specific requirements for connecting to, or instantiating, a logger.
  </p>
  
  <ul>
  <li><h4>org.apache.commons.logging.Log</h4></li>
  <p>
  The default <code>LogFactory</code> provided by JCL
  can be configured to instantiate a specific implementation of the
  <code>org.apache.commons.logging.Log</code> interface
  by setting the property of the same name (<code>org.apache.commons.logging.Log</code>).
  This property can be specified as a system property,
  or in the <code>commons-logging.properties</code> file,
  which must exist in the CLASSPATH.
  </p>
  
  <h4>Default logger if not plugged</h4>
  <p>
  The Jakarta Commons Logging SPI uses the
  implementation of the <code>org.apache.commons.logging.Log</code>
  interface specified by the system property
  <code>org.apache.commons.logging.Log</code>.
  If the property is not specified or the class is not available then the JCL
  provides access to a default logging toolkit by searching the CLASSPATH
  for the following toolkits, in order of preference:
  <ul>
  <li><a href="http://jakarta.apache.org/log4j/docs/index.html">Log4J</a></li>
  <li>JDK 1.4</li>
  <li>JCL SimpleLog</li>
  </ul>
  </p>
  
  <li><h4>org.apache.commons.logging.LogFactory</h4></li>
  <p>
  If desired, the default implementation of the
  <code>org.apache.commons.logging.LogFactory</code>
  interface can be overridden,
  allowing the JDK 1.3 Service Provider discovery process
  to locate and create a LogFactory specific to the needs of the application.
  Review the Javadoc for the <code>LogFactoryImpl.java</code>
  for details.
  <p>
  </ul>
  
  <h3><a NAME="Mechanism">Mechanism</a></h3>
  <ul>
  <li><h5>Life cycle</h5></li>
  The JCL LogFactory implementation must assume responsibility for
  either connecting/disconnecting to a logging toolkit,
  or instantiating/initializing/destroying a logging toolkit.
  <br>&nbsp;
  <li><h5>Exception handling</h5></li>
  The JCL Log interface doesn't specify any exceptions to be handled,
  the implementation must catch any exceptions.
  <br>&nbsp;
  <li><h5>Multiple threads</h5></li>
  The JCL Log and LogFactory implementations must ensure
  that any synchronization required by the logging toolkit
  is met.
  </ul>
  
  <h3><a NAME="Configuring the Logger Implementation">Configuring the Logger Implementation</a></h3>
  The Jakarta Commons Logging (JCL) SPI
  can be configured to use different logging toolkits.
  <p>
  Configuration of the behavior of the JCL ultimately depends upon the
  logging toolkit being used.
  The JCL SPI uses
  <a href="http://jakarta.apache.org/log4j/docs/index.html">Log4J</a>
  by default if it is available (in the CLASSPATH).
  <h4>Log4J</h4>
  As
  <a href="http://jakarta.apache.org/log4j/docs/index.html">Log4J</a>
  is the default logger,
  a <i>few</i> details are presented herein to get the developer/integrator going.
  <p>
  Configure Log4J using system properties and/or a properties file:
  <ul>
  <li><h5>log4j.configuration=<i>log4j.properties</i></h5></li>
  Use this system property to specify the name of a Log4J configuration file.
  If not specified, the default configuration file is <i>log4j.properties</i>.
  
  <br>&nbsp;
  <li><h5>log4j.rootCategory=<i>priority</i> [, <i>appender</i>]*</h5></li>
  Set the default (root) logger priority.
  
  <br>&nbsp;
  <li><h5>log4j.logger.<i>logger.name</i>=<i>priority</i></h5></li>
  Set the priority for the named logger
  and all loggers hierarchically lower than, or below, the
  named logger.
  <i>logger.name</i> corresponds to the parameter of
  <code>LogFactory.getLog(<i>logger.name</i>)</code>,
  used to create the logger instance.  Priorities are:
  <code>DEBUG</code>,
  <code>INFO</code>,
  <code>WARN</code>,
  <code>ERROR</code>,
  or <code>FATAL</code>.
  <p>
  Log4J understands hierarchical names,
  enabling control by package or high-level qualifiers:
  <code>log4j.logger.org.apache.component=DEBUG</code>
  will enable debug messages for all classes in both
  <code>org.apache.component</code>
  and
  <code>org.apache.component.sub</code>.
  Likewise, setting
  <code>log4j.logger.org.apache.component=DEBUG</code>
  will enable debug message for all 'component' classes,
  but not for other Jakarta projects.
  <br>&nbsp;
  <li><h5>log4j.appender.<i>appender</i>.Threshold=<i>priority</i></h5></li>
  Log4J <i>appenders</i> correspond to different output devices:
  console, files, sockets, and others.
  If appender's <i>threshold</i>
  is less than or equal to the message priority then
  the message is written by that appender.
  This allows different levels of detail to be appear
  at different log destinations.
  <p>
  For example: one can capture DEBUG (and higher) level information in a logfile,
  while limiting console output to INFO (and higher).
  </ul>
  
  
  </body>
  </html>
  
  
  

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message