This section contains information on the following subjects:
System administrators and developers configure logging output and filter log messages to troubleshoot errors or to receive notification for specific events.
The following tasks describe some logging configuration scenarios:
This release provides a commons-logging
interface. The interface provides commons.logging.LogFactory
and Log
interface implementations. It includes an extension of the org.apache.commons.logging.LogFactory
class that acts as a factory to create an implementation of the org.apache.commons.logging.Log
that delegates to the LoggingService
in the logging module. The name of this default implementation is weblogic.logging.commons.LogFactoryImpl
.
See
http://jakarta.apache.org/commons/logging/apidocs/index.html
.
The following provides information on setting the log factory using system properties:
org.apache.commons.logging.LogFactory
.-Dorg.apache.commons.logging.LogFactory= weblogic.logging.commons.LogFactoryImpl
import org.apache.commons.logging.LogFactory;
System.setProperty(LogFactory.FACTORY_PROPERTY, "weblogic.logging.commons.LogFactoryImpl");
org.apache.commons.logging.impl.LogFactoryImpl
implementation is available in the commons logging jar. For example:-Dorg.apache.commons.logging.LogFactory= org.apache.commons.logging.impl.LogFactoryImpl
or the equivalent programming would be:
System.setProperty(LogFactory.FACTORY_PROPERTY, "org.apache.commons.logging.impl.LogFactoryImpl");
Each log message has an associated severity level. The level gives a rough guide to the importance and urgency of a log message. Predefined severities, ranging from TRACE
to EMERGENCY
, which are converted to a log level when dispatching a log request to the logger. A log level object can specify any of the following values, from lowest to highest impact:
TRACE
, DEBUG
, INFO
, NOTICE
, WARNING
, ERROR
, CRITICAL
, ALERT
, EMERGENCY
You can set a log severity level on the logger and the handler. When set on the logger, none of the handlers receive an event which is rejected by the logger. For example, if you set the log level to NOTICE
on the logger, none of the handlers will receive INFO
level events. When you set a log level on the handler, the restriction only applies to that handler and not the others. For example, turning DEBUG
off for the File Handler means no DEBUG
messages will be written to the log file, however, DEBUG
messages will be written to standard out.
Table 10-1 lists the severity levels of log messages.
The system generates many messages of lower severity and fewer messages of higher severity. For example, under normal circumstances, they generate many INFO
messages and no EMERGENCY
messages.
The system writes a message to sdtout and the specified log file, consisting of the Timestamp, Severity, Subsystem, and the Message, along with the stacktrace if any. Each attribute is contained between angle brackets.
The following is an example of a message in the server log file:
<May 02, 2007 10:46:51 AM EST> <Notice> <CommonTestSubsystem> <BEA-123456>
<Another Commons test message>
When the system writes a message to standard out, the output does not include the ####
prefix and does not include the Server Name, Machine Name, Thread ID, User ID, Transaction ID, Diagnostic Context ID, and Raw Time Value fields.
The following is an example of how the message from the previous section would be printed to standard out:
<Sept 22, 2004 10:51:10 AM EST> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode>
In this example, the message attributes are: Locale-formatted Timestamp, Severity, Subsystem, Message ID, and Message Text.
WebLogic Event Server has a low-level framework logger that is started before the OSGi framework. It is used to report logging event deep inside the OSGi framework and function as a custom default for the logging subsystem before it is configured.
For example, a user may see some log message, which has lower level or severity than what is set in the config.xml
but higher or equals to what is set on the Launcher command line on the console or in the log file. Until the logging subsystem has started, log messages come from the framework logger and use the framework logging level to filter messages.
org.apache.commons.logging.LogFactory
to weblogic.logging.commons.LogFactoryImpl
.
This LogFactory
creates instances of weblogic.logging.commons.LogFactoryImpl
that implement the org.apache.commons.logging.Log
interface.
LogFactory
, get a reference to the Commons Log
object by name. This name appears as the subsystem name in the log file.
Log
object to issue log requests to logging services.
The Commons Log
interface methods accept an object. In most cases, this will be a string containing the message text.
The Commons LogObject
takes a message ID, subsystem name, and a string message argument in its constructor. See org.apache.commons.logging at http://jakarta.apache.org/commons/logging/api/index.html
.
weblogic.logging.commons.LogImpl
log methods direct the message to the server log.import org.apache.commons.logging.LogFactory;
import org.apache.commons.logging.Log;
public class MyCommonsTest {
public void testCommonsLogging() {
System.setProperty(LogFactory.FACTORY_PROPERTY,
"weblogic.logging.commons.LogFactoryImpl");
Log clog = LogFactory.getFactory().getInstance("MyCommonsLogger");
// Log String objects
clog.debug("Hey this is common debug");
clog.fatal("Hey this is common fatal", new Exception());
clog.error("Hey this is common error", new Exception());
clog.trace("Dont leave your footprints on the sands of time");
}
}
The following sections provide information on configuring WebLogic Event Server logging:
This section provides information on the logging-service configuration object:
See log-file.
|
||
Defines the threshold importance of the messages that are propagated to the handlers.
The default value is |
||
This section provides information on the log-stdout
configuration object:
Valid values are: |
||
This section provides information on the log-file
configuration object:
Specifies the directory where old rotated files are stored. If not set, the old files are stored in the same directory as the base log file. |
||
The following sections provide information on how to use the WebLogic Event Server debugging feature:
You can set a system property on the Java command line by using the following steps:
For example: -Dcom.bea.core.debug.DebugSDS=true
Use the following steps to configure debugging from a configuration file:
See Example Debug Configuration.
The following table provides the supported debug flags for this release:
The following code provides an example debug configuration to turn on Simple Declarative Services (SDS) debugging in the config.xml file
:
<config>
<debug>
<debug-properties>
<DebugSDS>true</DebugSDS>
</debug-properties>
</debug>
<logging-service>
<logger-severity>Debug
</logger-severity>
<stdout-config>logStdout
</stdout-config>
<log-file-config>
logFile<
/log-file-config>
</logging-service>
<log-file><name
>logFile
</name><
log-file-severity>Debug
</log-file-severity>
<number-of-files-limited>true</number-of-files-limited>
<rotated-file-count>4</rotated-file-count>
<rotate-log-on-startup-enabled>true</rotate-log-on-startup-enabled>
</log-file>
<log-stdout>
<name>logStdout
</name>
<stdout-severity>Debug
</stdout-severity>
</log-stdout>
</config>
Log4j is an open source tool developed for putting log statements in your application. Log4j has three main components:
The Log4j Java logging facility was developed by the Jakarta Project of the Apache Foundation. See:
http://logging.apache.org/log4j/docs/
http://logging.apache.org/log4j/docs/api/index.html
http://logging.apache.org/log4j/docs/manual
.
Log4j defines a Logger
class. An application can create multiple loggers, each with a unique name. In a typical usage of Log4j, an application creates a Logger
instance for each application class that will emit log messages. Loggers exist in a namespace hierarchy and inherit behavior from their ancestors in the hierarchy.
Log4j defines appenders (handlers) to represent destinations for logging output. Multiple appenders can be defined. For example, an application might define an appender that sends log messages to standard out, and another appender that writes log messages to a file. Individual loggers might be configured to write to zero or more appenders. One example usage would be to send all logging messages (all levels) to a log file, but only ERROR
level messages to standard out.
Log4j defines layouts to control the format of log messages. Each layout specifies a particular message format. A specific layout is associated with each appender. This lets you specify a different log message format for standard out than for file output, for example.
The default configuration file is log4j.propertie
s. It can be overridden by using the log4j.configuration
system property. See
https://www.qos.ch/shop/products/log4j/log4j-Manual.jsp
.
The following is an example of a log4j.properties
file:
log4j.rootLogger=debug, R
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=D:/log4j/logs/mywebapp.log
log4j.appender.R.MaxFileSize=10MB
log4j.appender.R.MaxBackupIndex=10
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n
log4j.logger=DEBUG, R
To specify logging to a Log4j Logger
, set the following system properties on the command line:
-Dorg.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryimpl
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
-Dlog4j.configuration=
<URL>
/log4j.properties