1.5 Logging with log4j

With the log4j.xml configuration file, you can do the following:

In the absence of a configuration file (such as log4j.xml or log4j.properties), Viewpoint saves logs to the/tmp directory, or to the Tomcat temporary directory ($CATALINA_HOME/temp/)

Note The log4j.xml file is checked every 10 seconds for changes. Therefore, after any changes are made to the configuration, it is not necessary to restart Viewpoint, but it may take up to 10 seconds for the changes to be reflected in the logs.

The following is an example of the Viewpoint default logging properties:

<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd" >
<log4j:configuration>

  <appender name="file" class="org.apache.log4j.RollingFileAppender">
    <param name="maxFileSize" value="50MB" />
    <param name="maxBackupIndex" value="5" />
    <param name="File" value="${VIEWPOINT_HOME}/log/viewpoint.log" />
    <layout class="org.apache.log4j.PatternLayout">
      <param name="ConversionPattern" value="%d{dd MMM yyyy HH:mm:ss,SSS} %5p %c{1}:%L - %m%n" />
    </layout>
  </appender>

  <!-- Logger for Viewpoint server code -->
  <logger name="com.cri" additivity="false">
    <level value="info"></level>
    <appender-ref ref="file"></appender-ref>
  </logger>

  <!-- Logger for Viewpoint security -->
  <logger name="com.cri.security" additivity="false">
    <level value="debug"></level>
    <appender-ref ref="file"></appender-ref>
  </logger>

  <!-- Logger for external Java API classes -->
  <logger name="com.ace" additivity="false">
    <level value="info"></level>
    <appender-ref ref="file"></appender-ref>
  </logger>

  <!-- Logger for low level internal Java API classes -->
  <logger name="com.moab" additivity="false">
    <level value="info"></level>
    <appender-ref ref="file"></appender-ref>
  </logger>

  <!-- Logging for everything but the Viewpoint code and Moab Java API. This includes 
  hibernate and its associated connection pool -->
  <root>
    <priority value="info"></priority>
    <appender-ref ref="file"></appender-ref>
  </root>

</log4j:configuration>

1.5.0.1 Appender

An output destination is called an appender. Log4j allows logging requests to print to multiple destinations. Multiple appenders can be attached to a logger. The <appender> tag describes the logger type, which is a file appender. This appends the log to the specified file in the appender. The Java System property VIEWPOINT_HOME is used. This is set to the environment variable of $VIEWPOINT_HOME upon Web application startup. The default path to the files that contain the logs are contained at /opt/viewpoint/log/viewpoint.log.

1.5.0.2 Logger

The <logger> tags describe the different log levels that can be changed according to the Java packages of the source code. The list that follows describes the packages used in the default configuration. Note also that each logger tag has an associated value that indicates the verbosity level. More information on verbosity levels is available in Setting Logging Verbosity Levels below.

setting_verbosity_levels
Setting Logging Verbosity Levels

Each logger tag requires an associated level of verbosity. The levels are cumulative, meaning that each level also logs the messages logged by levels hierarchically ordered below it. For example, if an administrator configures a logging level of info, method calls to logger.info(), logger.warn(), logger.error(), and logger.fatal() are also logged. The following table offers a brief description of the various log4j verbosity levels:

Verbosity Levels
Level Definition
All data.
Normal operations.
Significant system events such as application initialization, logging initialization, and occurrence of rare global events.
Recoverable exceptions or unexpected state.
Unrecoverable request exceptions or recoverable system errors.
Indicates occurrence of an unrecoverable system error resulting in a crash of the application.

Example

In Viewpoint, at application startup, a dynamically loaded class authenticates HTTP requests. However, if the class does not exist in the classpath, or if there is some other type of exception in creating an instance of the class, a message is logged via logger.fatal() to explain why the application failed.