This chapter describes how to configure logging and debugging for Oracle Event Processing, including using the Oracle Event Processing logging service, Log4j, the and Apache Commons logging API, as well as configuring debugging options.
This chapter includes the following sections:
Section 15.1, "Overview of Logging and Debugging Configuration"
Section 15.2, "Configuring the Oracle Event Processing Logging Service"
Section 15.5, "Configuring Oracle Event Processing Debugging Options"
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:
Stop DEBUG
and INFO
messages from going to the log file.
Allow INFO
level messages from the HTTP subsystem to be published to the log file, but not to standard out.
Specify that a handler publishes messages that are WARNING
severity level or higher.
Specify a default logging level for the entire Oracle Event Processing server, and then have a specific Oracle Event Processing module override the default logging level. For example, the default logging level of the server could be WARNING
while the logging level of the CEP module is DEBUG
.
Configure a logging level for a user-application deployed to Oracle Event Processing. In this case, the application must use the Commons Apache Logging Framework if the application is required to output log messages into the single server-wide log file to which the modules of the server itself also log their messages.
Oracle Event Processing supports the following logging systems:
Oracle Event Processing also provides a variety of debugging options that you can enable and disable to help diagnose your Oracle Event Processing applications. See Section 15.5, "Configuring Oracle Event Processing Debugging Options".
Note:
For information on Oracle Event Processing security auditor logging, see Section 10.10, "Configuring the Oracle Event Processing Security Auditor".
Note:
For information how to parse message catalogs to validate and generate classes used for localizing text in log messages, see "Managing Log Message Catalogs" in the Oracle Fusion Middleware Developer's Guide for Oracle Event Processing for Eclipse.
Oracle Event Processing 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
.
This section describes the following:
For more information, see http://jakarta.apache.org/commons/logging/apidocs/index.html
.
The following provides information on setting the log factory using system properties:
The highest priority is given to the system property org.apache.commons.logging.LogFactory
.
You can set logging from the command line using:
-Dorg.apache.commons.logging.LogFactory=weblogic.logging.commons.LogFactoryImpl
You can programmatically implement the logging by:
import org.apache.commons.logging.LogFactory; System.setProperty( LogFactory.FACTORY_PROPERTY, "weblogic.logging.commons.LogFactoryImpl" );
The weblogic.logging.commons.LogFactoryImpl
is the default log factory, if not explicitly set.
To use another logging implementation, you must use the standard commons logging factory implementation. The 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 (left-most) to highest (right-most) 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 Event Processing 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 15-1 lists the severity levels of log messages.
Table 15-1 Log Message Severity
Severity | Meaning |
---|---|
TRACE |
Used for messages from the Diagnostic Action Library. Upon enabling diagnostic instrumentation of server and application classes, |
DEBUG |
A debug message was generated. |
INFO |
Used for reporting normal operations, a low-level informational message. |
NOTICE |
An informational message with a higher level of importance. |
WARNING |
A suspicious operation or configuration has occurred but it might not affect normal operation. |
ERROR |
A user error has occurred. The system or application can handle the error with no interruption and limited degradation of service. |
CRITICAL |
A system or service error has occurred. The system can recover but there might be a momentary loss or permanent degradation of service. |
ALERT |
A particular service is in an unusable state while other parts of the system continue to function. Automatic recovery is not possible; the immediate attention of the administrator is needed to resolve the problem. |
EMERGENCY |
The server is in an unusable state. This severity indicates a severe system failure or panic. |
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.
By default, Oracle Event Processing server writes log messages to the server.log
and consoleoutput.log
files in the ORACLE_CEP_HOME
/user_projects/domains/
DOMAIN_DIR
/
servername
directory, where ORACLE_CEP_HOME
refers to the Oracle Event Processing installation directory (such as d:/oracle_cep
), DOMAIN_DIR
refers to the domain directory (such as my_domain
), and servername
refers to the server instance directory (such as server1
).
For information on configuring log file attributes, see Section 15.2.2, "log-file".
For information on server.log
file message format, see Section 15.1.1.4.1, "Format of Output to a Log File".
For information on consoleoutput.log
file message format, see Section 15.1.1.4.2, "Format of Output to Console, Standard Out, and Standard Error".
Oracle Event Processing server writes log messages in different formats depending on the type of log file it is writing to:
For more information on log files, see Section 15.1.1.3, "Log Files".
The system writes a message to the specified log file consisting of a ####
prefix, Timestamp
, Severity
, Subsystem
, Server Name
, Connection
, Thread ID
or User ID
or Transaction ID
, Message ID
, and the Message
, along with a stacktrace if any. Each attribute is contained between angle brackets.
The following is an example of a message in the server log file (split for readability; in practice, the message might be on one line):
####<Feb 25, 2009 10:23:32 AM EST> <Notice> <Deployment> <> <myServer> <RMI TCP Connection(4)-141.144.123.236> <> <> <> <1235575412801> <BEA-2045000> <The application bundle "Hello" was deployed successfully to file [C:\OracleCEP\user_projects\domains\ocep_domain\defaultserver\applications\Hello\Hello.jar] with version 1235575412708>
The system writes a message to the console, standard out, or standard error consisting of Locale-formatted Timestamp
, Severity
, Subsystem
, Message ID
, and Message
.
The following is an example of how the message from the previous section would be printed to standard out (split for readability; in practice, the message might be on one line):
<Feb 25, 2009 10:23:32 AM EST> <Notice> <Deployment> <BEA-2045000> <The application bundle "Hello" was deployed successfully to file [C:\OracleCEP\user_projects\domains\ocep_domain\defaultserver\applications\Hello\Hello.jar] with version 1235575412708>
Oracle Event Processing 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.
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:
The Log4j Project at http://logging.apache.org/log4j/
.
The Log4j API at http://logging.apache.org/log4j/1.2/apidocs/index.html
.
Short introduction to log4j at http://logging.apache.org/log4j/1.2/manual.html
.
For more information, see Section 15.3, "Configuring Log4j Logging"
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.
You configure Oracle Event Processing logging service attributes using Oracle Event Processing Visualizer or by editing the Oracle Event Processing server config.xml
file.
For more information on configuring logging using Oracle Event Processing Visualizer, see "Managing Logs" in the Oracle Fusion Middleware Visualizer User's Guide for Oracle Event Processing.
The config.xml
file is located in the ORACLE_CEP_HOME
/user_projects/domains/
DOMAIN_DIR
/
servername
/config
directory, where ORACLE_CEP_HOME
refers to the Oracle Event Processing installation directory (such as d:/oracle_cep
), DOMAIN_DIR
refers to the domain directory (such as my_domain
), and servername
refers to the server instance directory (such as server1
).
Example 15-1 shows a typical Oracle Event Processing server config.xml
file with logging elements.
Example 15-1 Oracle Event Processing Server config.xml File With Logging Configuration
<?xml version="1.0" encoding="UTF-8"?> <!--Sample XML file generated by XMLSpy v2007 sp2 (http://www.altova.com)--> <n1:config xsi:schemaLocation="http://www.bea.com/ns/wlevs/config/server wlevs_server_config.xsd" xmlns:n1="http://www.bea.com/ns/wlevs/config/server" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> ... <name>myLogService</name> <log-file-config>myFileConfig</log-file-config> <stdout-config>myStdoutConfig</stdout-config> <logger-severity>Notice</logger-severity> <logger-severity-properties> <entry> <key>LifeCycle</key> <value>Notice</value> </entry> <entry> <key>Management</key> <value>Notice</value> </entry> <entry> <key>CQLProcessor</key> <value>Notice</value> </entry> <entry> <key>EplProcessor</key> <value>Notice</value> </entry> <entry> <key>Stream</key> <value>Notice</value> </entry> <entry> <key>Ede</key> <value>Notice</value> </entry> <entry> <key>Cache</key> <value>Notice</value> </entry> <entry> <key>Adapters</key> <value>Notice</value> </entry> <entry> <key>Spring</key> <value>Notice</value> </entry> <entry> <key>Channel</key> <value>Notice</value> </entry> <entry> <key>Recplay</key> <value>Notice</value> </entry> <entry> <key>Monitor</key> <value>Notice</value> </entry> <entry> <key>Server</key> <value>Notice</value> </entry> <entry> <key>EventTrace</key> <value>Notice</value> </entry> <entry> <key>Deployment</key> <value>Notice</value> </entry> </logger-severity-properties> </logging-service> <log-file> <name>myFileConfig</name> <rotation-type>none</rotation-type> </log-file> <log-stdout> <name>myStdoutConfig</name> <stdout-severity>Debug</stdout-severity> </log-stdout> </n1:config>
The following sections provide information on configuring Oracle Event Processing logging:
This section provides information on the logging-service
element:
Table 15-2 Configuration Parameters for logging-service
Parameter | Type | Description |
---|---|---|
name |
String |
The name of this configuration object. |
log-file-config |
String |
The configuration of the log file and its rotation policies. |
stdout-config |
String |
The name of the |
logger-severity |
String |
Defines the threshold importance of the messages that are propagated to the handlers. The default value is To see Valid values are: |
logger-severity-properties |
One or more |
List of name-value pairs, enclosed in an See Section 15.2.4, "Configuring Severity for an Individual Module." |
This section provides information on the log-file
element:
Table 15-3 Configuration Parameters for log-file
Parameter | Type | Description |
---|---|---|
name |
String |
The name of this configuration object. |
base-log-file-name |
String |
The log file name. Default value is |
log-file-severity |
String |
Specifies the least important severity of messages written to the log file. Default value is Valid values are:
|
log-file-rotation-dir |
String |
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. |
rotation-type |
String |
Specifies how rotation is performed based on size, time, or not at all. Valid values are:
|
rotation-time |
String |
The time in Default is |
rotation-time-span-factor |
Long |
Factor applied to the timespan to determine the number of milliseconds that becomes the frequency of time based log rotations. Default is |
rotated-file-count |
Integer |
Specifies the number of old rotated files to keep if |
rotation-size |
Integer |
The size threshold, in KB, at which the log file is rotated. Default is |
rotation-time-span |
Integer |
Specifies the interval for every time-based log rotation. Default value is |
rotate-log-on-startup-enabled |
Boolean |
If |
number-of-files-limited |
Boolean |
If |
This section provides information on the log-stdout
element:
Table 15-4 Configuration Parameters for log-stdout
Parameter | Type | Description |
---|---|---|
name |
String |
The name of this configuration object. |
stdout-severity |
String |
The threshold severity for messages sent to stdout. Default value is Valid values are:
|
stack-trace-depth |
Integer |
The number of stack trace frames to display on stdout. A default value of |
stack-trace-enabled |
Boolean |
If true, stack traces are dumped to the console when included in logged messages. Default value is |
Individual modules of Oracle Event Processing can specify their logging severity. This severity overrides the default logging severity of Oracle Event Processing server.
You do this by specifying an entry
child element in the logger-severity-properties
element in the Oracle Event Processing server config.xml
file. You may specify multiple entry
child elements for any number of modules.
To configure severity for an individual module:
Edit the Oracle Event Processing server config.xml
file.
Add an entry
child element to the logger-severity-properties
element as Example 15-2 shows.
Example 15-2 entry Child Element of the logger-severity-properties Element
<logging-service> <name>myLogService</name> <logger-severity>Warning</logger-severity> <logger-severity-properties> ... <entry> <key>CQLProcessor</key> <value>Debug</value> </entry> ... </logger-severity-properties> ... </logging-service>
Set the key
element to any of the following:
Component name: a component name constant exactly as Table 15-5 lists.
Table 15-5 Logging Component Name Constants
Component Name Constant | Description |
---|---|
|
Applies to log messages from adapter instances running on the Oracle Event Processing server. |
|
Applies to log messages from caching systems and cache instances running on the Oracle Event Processing server. |
|
Applies to log messages from channels running on the Oracle Event Processing server. |
|
Applies to log messages from Oracle CQL processors running on the Oracle Event Processing server. |
|
Applies to log messages from the CQLEngine, which is at the core of each CQLProcessor. |
|
Applies to log messages from the CQLEngine, which is at the core of each CQLProcessor |
|
Applies to log messages from Oracle Coherence, including messages related to clustering. The value you enter here is mapped to Oracle Coherence severity levels in the following way: Error: 1 Warning: 2 Notice: 3 Info: 4 Debug: 5 Trace: 9 You can customize logging from Oracle Coherence by overriding the |
|
Applies to log messages from EPL processors running on the Oracle Event Processing server. |
|
Applies to log messages from the Event-Driven Environment, the Oracle Event Processing server event-dispatching infrastructure. |
|
When set to At the <May 26, 2009 5:53:49 PM PDT> <Info> <EventTrace> <BEA-000000> <Application [helloworld], Stage [helloworldOutputChannel] received insert event> At the <May 26, 2009 6:02:34 PM PDT> <Debug> <EventTrace> <BEA-000000> <Application [helloworld], Stage [helloworldOutputChannel] received insert event [HelloWorldEvent: HelloWorld - the current time is: 6:02:34 PM]> |
|
Applies to log messages from Oracle Event Processing server and application lifecycle operations. |
|
Applies to log messages from Oracle Event Processing server general JMX-related management API operations. |
|
Applies to log messages from the Oracle Event Processing server monitoring service. |
|
Applies to log messages from Oracle Event Processing server event recording and playback operations. |
|
Applies to log messages from Spring container operations. |
|
Applies to log messages from stream instances running on the Oracle Event Processing server. |
For example:
<entry> <key>CQLProcessor</key> <value>Debug</value> </entry>
Application name: the module name of any Oracle Event Processing server or user-defined application. For example:
<entry> <key>sample.HelloWorld</key> <value>Debug</value> </entry>
Package name: the name of any Oracle Event Processing server or user-supplied Java package. For example:
<entry> <key>com.bea.wlevs.ede</key> <value>Debug</value> </entry>
For more information on Oracle Event Processing server packages, see the Oracle Fusion Middleware Java API Reference for Oracle Event Processing.
Class name: the fully qualified name of any Oracle Event Processing server or user-defined class. For example:
<entry> <key>com.bea.wlevs.cep.core.EPRuntimeImpl</key> <value>Debug</value> </entry>
For more information on Oracle Event Processing server classes, see the Oracle Fusion Middleware Java API Reference for Oracle Event Processing.
Set the value
element to a severity level.
See Section 15.1.1.2, "Using Log Severity Levels".
For example:
<entry> <key>CQLProcessor</key> <value>Debug</value> </entry>
This severity level applies to the module you specified in the key
element and overrides the default Oracle Event Processing server logging severity level set in the logger-severity
element that Example 15-2 shows.
Repeat from step 2 for any other modules.
Save and close the config.xml
file.
Oracle Event Processing supports the open-source log4j logging system.
This section describes the following tasks:
For more information, see Section 15.1.3, "Log4j Logger".
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:
Example 15-3 Example 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
Update the MANIFEST.MF
file of your application to import the following required Log4j packages.
Import-Package: org.apache.log4j;version="1.2.13", org.apache.log4j.config;version="1.2.13", ...
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
Another very useful command line property is -Dlog4j.debug=true
. Use this property when log4j output fails to appear or you get cryptic error messages.
If log4j output fails to appear or you get cryptic error messages, consider using the command line property -Dlog4j.debug=true
on the command line.
For more information, see Section 15.3.3, "Enabling Log4j Logging".
You can use Apache Commons logging API in your Oracle Event Processing applications to log application-specific messages to the Oracle Event Processing server.log
and consoleoutput.log
files.
To use the commons logging API:
Set the system property 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.
From the LogFactory
, get a reference to the Commons Log
object by name.
This name appears as the subsystem name in the log file.
Use the 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
.
The weblogic.logging.commons.LogImpl
log methods direct the message to the server log.
Example 15-4 Commons Code Example
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"); } }
Table 15-6 lists the debugging options that Oracle Event Processing provides. You can enable and disable these debugging options to help diagnose problems with your Oracle Event Processing applications.
Debug Flag | Description |
---|---|
com.bea.core.debug.DebugBootBundle |
Boot Debugging |
com.bea.core.debug.DebugBootBundle.stdout |
Boot Debugging debug strings go to stdout |
com.bea.core.debug.DebugCM |
Configuration Manager |
com.bea.core.debug.DebugCM.stdout |
Configuration Manager debug strings go to stdout |
com.bea.core.debug.DebugConfigurationRuntime |
Runtime information from the Runtime MBeans |
com.bea.core.debug.DebugCSS |
CSS |
com.bea.core.debug.DebugCSS.stdout |
CSS debug strings go to stdout |
com.bea.core.debug.DebugCSSServices |
CSS Services |
com.bea.core.debug.DebugCSSServices.stdout |
CSS Services debug strings go to stdout |
com.bea.core.debug.DebugJDBCConn |
JDBC Connection |
com.bea.core.debug.DebugJDBCInternal |
JDBC Internal |
com.bea.core.debug.DebugJDBCRMI |
JDBC RMI |
com.bea.core.debug.DebugJDBCSQL |
JDBC SQL |
com.bea.core.debug.DebugJTA2PC |
JTA 2PC |
com.bea.core.debug.DebugJTA2PCDetail |
JTA 2PCDetail |
com.bea.core.debug.DebugJTA2PCStackTrace |
JTA 2PCStackTrace |
com.bea.core.debug.DebugJTAGateway |
JTA Gateway |
com.bea.core.debug.DebugJTAGatewayStackTrace |
JTA GatewayStackTrace |
com.bea.core.debug.DebugJTAHealth |
JTA Health |
com.bea.core.debug.DebugJTAJDBC |
JTA JDBC |
com.bea.core.debug.DebugJTALifecycle |
JTA Lifecycle |
com.bea.core.debug.DebugJTALLR |
JTA LLR |
com.bea.core.debug.DebugJTAMigration |
JTA Migration |
com.bea.core.debug.DebugJTANaming |
JTA Naming |
com.bea.core.debug.DebugJTANamingStackTrace |
JTA NamingStackTrace |
com.bea.core.debug.DebugJTANonXA |
JTA NonXA |
com.bea.core.debug.DebugJTAPropagate |
JTA Propagate |
com.bea.core.debug.DebugJTARecovery |
JTA Recovery |
com.bea.core.debug.DebugJTAResourceHealth |
JTA ResourceHealth |
com.bea.core.debug.DebugJTATLOG |
JTA TLOG |
com.bea.core.debug.DebugJTAXA |
JTA XA |
com.bea.core.debug.DebugJTAXAStackTrace |
JTA XAStackTrace |
com.bea.core.debug.DebugNetIO |
NetIO |
com.bea.core.debug.DebugOX |
OSGi to JMX (OX) |
com.bea.core.debug.DebugOX.stdout |
OSGi to JMX (OX), debug goes to standard out. |
com.bea.core.debug.DebugSCP |
Simple Configuration Provider |
com.bea.core.debug.DebugSCP.stdout |
Simple Configuration Provider debug strings go to stdout |
com.bea.core.debug.DebugSDS |
Simple Declarative Services |
com.bea.core.debug.DebugSDS.stdout |
SDS debug strings go to stdout |
com.bea.core.debug.DebugServiceHelper |
Service Helper |
com.bea.core.debug.DebugServiceHelper.stdout |
Service Helper debug strings go to stdout |
com.bea.core.debug.DebugStoreAdmin |
Store Administration |
com.bea.core.debug.DebugStoreIOLogical |
Store IOLogical |
com.bea.core.debug.DebugStoreIOLogicalBoot |
Store IOLogicalBoot |
com.bea.core.debug.DebugStoreIOPhysical |
Store IOPhysical |
com.bea.core.debug.DebugStoreIOPhysicalVerbose |
Store IOPhysicalVerbose |
com.bea.core.debug.DebugStoreXA |
Store XA |
com.bea.core.debug.DebugStoreXAVerbose |
Store XAVerbose |
com.bea.core.debug.servicehelper.dumpstack |
Dump stack traces when Service Helper times out. |
The following sections provide information on how to use these Oracle Event Processing debugging options:
Section 15.5.1, "How to Configure Oracle Event Processing Debugging Options Using System Properties"
If you are using Log4j logging, see also Section 15.3.4, "Debugging Log4j Logging".
Use the following steps to configure debugging using system properties.
In this procedure, you will turn on Simple Declarative Services (SDS) debugging (com.bea.core.debug.DebugSDS
from Table 15-6) using the Oracle Event Processing server startwlevs.sh
file.
To configure Oracle Event Processing debugging options using system properties:
Locate the DebugSDS
flag in Table 15-6:
com.bea.core.debug.DebugSDS
Create a property by prepending -D
to the flag:
-Dcom.bea.core.debug.DebugSDS
Enable this debug flag by setting the property to true
:
-Dcom.bea.core.debug.DebugSDS=true
Start the Oracle Event Processing server using the startwlevs.sh
with this property:
./startwlevs.sh -Dcom.bea.core.debug.DebugSDS=true
Use the following steps to configure debugging from a configuration file.
In this procedure, you will turn on Simple Declarative Services (SDS) debugging (com.bea.core.debug.DebugSDS
from Table 15-6) in the Oracle Event Processing server config.xml
file.
To configure Oracle Event Processing debugging options using a configuration file:
Locate the DebugSDS
flag in Table 15-6:
com.bea.core.debug.DebugSDS
Create an XML tag by omitting the com.bea.core.debug.
package name from the flag name:
<DebugSDS></DebugSDS>
Edit the Oracle Event Processing server config.xml
file and add a debug
element with a debug-properties
child element as Example 15-5 shows.
Add your DebugSDS
element to the debug-properties
element as Example 15-5 shows.
Enable this debug flag by setting the DebugSDS
element to true
as Example 15-5 shows.
Set logger-severity
to Debug
in the logging-service
element as Example 15-6 shows.
Set stdout-severity
to Debug
in the log-stdout
element as Example 15-6 shows.
Example 15-6 Enabling Debug Logging
<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>