|
|
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:
DEBUG and INFO messages from going to the log file.INFO level messages from the HTTP subsystem to be published to the log file, but not to standard out.WARNING severity level or higher.
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, 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, the handler, and a user application. 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.
Users (Oracle CEP module owners or owners of user applications) are free to define the names that represent the logging category type used by the Apache commons logging for individual modules. However if the category names are defined as package names then based on the naming convention, a logging level hierarchy is assumed by default. For example, if two modules name their logging category names com.oracle.foo and com.oracle.foo.bar, then com.oracle.foo becomes the root node of com.oracle.foo.bar. This way any logging level applied to parent node (com.oracle.foo) automatically applies to com.oracle.foo.bar, unless the child node overrides the parent.
In other words, if the logging severity is specified for a node, it is effective unless the severity is inherited from the nearest parent whose severity is explicitly configured. The root node is always explicitly configured, so if nothing else if set, then all the nodes inherit the severity from the root.
Table 12-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.
Oracle CEP 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 equal 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 Oracle CEP logging:
This section provides information on the <logging-service> configuration object:
|
See log-file.
|
||
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. |
||
Individual modules of Oracle CEP can specify their logging severity. This severity overrides the default logging severity of Oracle CEP, which is Notice. You do this by specifying the name of the module package and its logging severity as <logger-severity-properties> element within the log configuration in the server’s config.xml file. Multiple packages or loggers can be specified in the <logger-severity-properties> element as name value pairs.
The following sample config.xml shows how to change the logging severity for a number of modules of Oracle CEP:
<logging-service>
<name>myLogService</name><logger-severity>Warning</logger-severity><stdout-config>myStdoutConfig</stdout-config>
<logger-severity-properties>
<entry>
<key>com.bea.wlevs.ede</key>
<value>Debug</value>
</entry>
<entry>
<key>sample.HelloWorld</key>
<value>Debug</value>
</entry>
<entry>
<key>com.bea.wlevs.cep.core.EPRuntimeImpl</key>
<value>Debug</value>
</entry>
</logger-severity-properties>
<log-file-config>myLogFileConfig</log-file-config>
</logging-service>
In the example, the default logging severity for the server is WARNING. However, the logging severity for any modules in the com.bea.wlevs.ede package, the sample.HelloWorld user application, and the com.bea.wlevs.cep.core.EPRuntimeImpl class is DEBUG.
The following sections provide information on how to use the Oracle CEP 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>
The following sections provide information on using Log4j:
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.htmlhttp://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.properties. 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
|