Skip Headers
Oracle® Fusion Middleware Administrator's Guide for Oracle Complex Event Processing
11g Release 1 (11.1.1.6.3)

Part Number E14300-10
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

15 Configuring Logging and Debugging for Oracle CEP

This chapter describes how to configure logging and debugging for Oracle Complex Event Processing (Oracle CEP), including using the Oracle CEP logging service, Log4j, the and Apache Commons logging API, as well as configuring debugging options.

15.1 Overview of Logging and Debugging Configuration

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:

Oracle CEP supports the following logging systems:

Oracle CEP also provides a variety of debugging options that you can enable and disable to help diagnose your Oracle CEP applications. See Section 15.5, "Configuring Oracle CEP Debugging Options".

Note:

For information on Oracle CEP security auditor logging, see Section 10.10, "Configuring the Oracle CEP 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 Complex Event Processing for Eclipse.

15.1.1 Commons Apache Logging Framework

Oracle CEP 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.

15.1.1.1 Setting the Log Factory

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"
    );
    

15.1.1.2 Using Log Severity Levels

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 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 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, TRACE messages follow the request path of a method.

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.

15.1.1.3 Log Files

By default, Oracle CEP 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 CEP 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".

15.1.1.4 Log Message Format

Oracle CEP 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".

15.1.1.4.1 Format of Output to a Log File

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>
15.1.1.4.2 Format of Output to Console, Standard Out, and Standard Error

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>

15.1.2 OSGi Framework Logger

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.

15.1.3 Log4j Logger

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:

For more information, see Section 15.3, "Configuring Log4j Logging"

15.1.3.1 Loggers

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.

15.1.3.2 Appenders

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.

15.1.3.3 Layouts

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.

15.2 Configuring the Oracle CEP Logging Service

You configure Oracle CEP logging service attributes using Oracle CEP Visualizer or by editing the Oracle CEP server config.xml file.

For more information on configuring logging using Oracle CEP Visualizer, see "Managing Logs" in the Oracle Fusion Middleware Visualizer User's Guide for Oracle Complex 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 CEP 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 CEP server config.xml file with logging elements.

Example 15-1 Oracle CEP 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 CEP logging:

15.2.1 logging-service

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.

See Section 15.2.2, "log-file."

stdout-config 
String

The name of the stdout configuration object used to configure stdout output. See Section 15.2.3, "log-stdout."

logger-severity
String

Defines the threshold importance of the messages that are propagated to the handlers.

The default value is Info.

To see Debug and Trace messages, configure the logger-severity to either Debug or Trace.

Valid values are: Emergency, Alert, Critical, Error, Warning, Notice, Info, Debug, and Trace.

logger-severity-properties

One or more <entry> child elements.

List of name-value pairs, enclosed in an <entry> element, that list individual modules (package name, application name, class name, or component such as CQLProcessor) and their logging severity. These severities override the default severity of the Oracle CEP server.

See Section 15.2.4, "Configuring Severity for an Individual Module."


15.2.2 log-file

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 server.log.

log-file-severity
String

Specifies the least important severity of messages written to the log file. Default value is Trace.

Valid values are:

  • Emergency

  • Alert

  • Critical

  • Error

  • Warning

  • Notice

  • Info

  • Debug

  • Trace

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:

  • bySize

  • byTime

  • none

rotation-time
String

The time in k:mm format, where k is the hour specified in 24 hour notation and mm is the minutes.

Default is 00:00

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 3600000.

rotated-file-count
Integer

Specifies the number of old rotated files to keep if number-of-files-limited is true. Default value is 7.

rotation-size 
Integer

The size threshold, in KB, at which the log file is rotated. Default is 500.

rotation-time-span 
Integer

Specifies the interval for every time-based log rotation. Default value is 24.

rotate-log-on-startup-enabled
Boolean

If true, the log file is rotated on startup. Default value is true.

number-of-files-limited
Boolean

If true, old rotated files are deleted. Default is false.


15.2.3 log-stdout

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 Notice.

Valid values are:

  • Emergency

  • Alert

  • Critical

  • Error

  • Warning

  • Notice

  • Info

  • Debug

  • Trace

stack-trace-depth 
Integer

The number of stack trace frames to display on stdout.

A default value of -1 means all frames are displayed.

stack-trace-enabled 
Boolean

If true, stack traces are dumped to the console when included in logged messages. Default value is true.


15.2.4 Configuring Severity for an Individual Module

Individual modules of Oracle CEP can specify their logging severity. This severity overrides the default logging severity of Oracle CEP server.

You do this by specifying an entry child element in the logger-severity-properties element in the Oracle CEP server config.xml file. You may specify multiple entry child elements for any number of modules.

To configure severity for an individual module:

  1. Edit the Oracle CEP server config.xml file.

  2. 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>
    
  3. 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

      Adapters

      Applies to log messages from adapter instances running on the Oracle CEP server.

      Cache

      Applies to log messages from caching systems and cache instances running on the Oracle CEP server.

      Channel

      Applies to log messages from channels running on the Oracle CEP server.

      CQLProcessor

      Applies to log messages from Oracle CQL processors running on the Oracle CEP server.

      CQLServer

      Applies to log messages from the CQLEngine, which is at the core of each CQLProcessor.

      CQLServerTrace

      Applies to log messages from the CQLEngine, which is at the core of each CQLProcessor

      Coherence

      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 logging-config setting in its configuration. For example, you can override the default log destination used for Oracle Coherence (log4j) and use another. For more information on overriding configuration, see Section 6.1.3, "Configuring the Oracle Coherence Cluster".

      EplProcessor

      Applies to log messages from EPL processors running on the Oracle CEP server.

      Ede

      Applies to log messages from the Event-Driven Environment, the Oracle CEP server event-dispatching infrastructure.

      EventTrace

      When set to Info or Debug, allows you to trace events as they flow through the EPN for all applications. You can dynamically change the severity of this log key using Oracle CEP Visualizer.

      At the Info severity, you see log messages like:

      <May 26, 2009 5:53:49 PM PDT> <Info> <EventTrace> 
          <BEA-000000> <Application [helloworld], 
          Stage [helloworldOutputChannel] received insert event>
      

      At the Debug severity, the log messages include details of the event:

      <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]>
      

      Lifecycle

      Applies to log messages from Oracle CEP server and application lifecycle operations.

      Management

      Applies to log messages from Oracle CEP server general JMX-related management API operations.

      Monitor

      Applies to log messages from the Oracle CEP server monitoring service.

      Recplay

      Applies to log messages from Oracle CEP server event recording and playback operations.

      Spring

      Applies to log messages from Spring container operations.

      Stream

      Applies to log messages from stream instances running on the Oracle CEP server.


      For example:

      <entry>
          <key>CQLProcessor</key>
          <value>Debug</value>
      </entry>
      
    • Application name: the module name of any Oracle CEP server or user-defined application. For example:

      <entry>
          <key>sample.HelloWorld</key>
          <value>Debug</value>
      </entry>
      
    • Package name: the name of any Oracle CEP server or user-supplied Java package. For example:

      <entry>
          <key>com.bea.wlevs.ede</key>
          <value>Debug</value>
      </entry>
      

      For more information on Oracle CEP server packages, see the Oracle Fusion Middleware Java API Reference for Oracle Complex Event Processing.

    • Class name: the fully qualified name of any Oracle CEP 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 CEP server classes, see the Oracle Fusion Middleware Java API Reference for Oracle Complex Event Processing.

  4. 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 CEP server logging severity level set in the logger-severity element that Example 15-2 shows.

  5. Repeat from step 2 for any other modules.

  6. Save and close the config.xml file.

15.3 Configuring Log4j Logging

Oracle CEP supports the open-source log4j logging system.

This section describes the following tasks:

For more information, see Section 15.1.3, "Log4j Logger".

15.3.1 Configuring log4j Properties

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

15.3.2 Configuring Application Manifest

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",
    ...

15.3.3 Enabling Log4j Logging

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.

15.3.4 Debugging Log4j Logging

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".

15.4 Using the Apache Commons Logging API

You can use Apache Commons logging API in your Oracle CEP applications to log application-specific messages to the Oracle CEP server.log and consoleoutput.log files.

To use the commons logging API:

  1. 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.

  2. From the LogFactory, get a reference to the Commons Log object by name.

    This name appears as the subsystem name in the log file.

  3. 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.

  4. 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");
  }
}

15.5 Configuring Oracle CEP Debugging Options

Table 15-6 lists the debugging options that Oracle CEP provides. You can enable and disable these debugging options to help diagnose problems with your Oracle CEP applications.

Table 15-6 Debug Flags

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 CEP debugging options:

If you are using Log4j logging, see also Section 15.3.4, "Debugging Log4j Logging".

15.5.1 How to Configure Oracle CEP Debugging Options Using System Properties

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 CEP server startwlevs.sh file.

To configure Oracle CEP debugging options using system properties:

  1. Locate the DebugSDS flag in Table 15-6:

    com.bea.core.debug.DebugSDS
    
  2. Create a property by prepending -D to the flag:

    -Dcom.bea.core.debug.DebugSDS
    
  3. Enable this debug flag by setting the property to true:

    -Dcom.bea.core.debug.DebugSDS=true
    
  4. Start the Oracle CEP server using the startwlevs.sh with this property:

    ./startwlevs.sh -Dcom.bea.core.debug.DebugSDS=true
    

15.5.2 How to Configure Oracle CEP Debugging Options Using a Configuration File

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 CEP server config.xml file.

To configure Oracle CEP debugging options using a configuration file:

  1. Locate the DebugSDS flag in Table 15-6:

    com.bea.core.debug.DebugSDS
    
  2. Create an XML tag by omitting the com.bea.core.debug. package name from the flag name:

    <DebugSDS></DebugSDS>
    
  3. Edit the Oracle CEP server config.xml file and add a debug element with a debug-properties child element as Example 15-5 shows.

  4. Add your DebugSDS element to the debug-properties element as Example 15-5 shows.

  5. Enable this debug flag by setting the DebugSDS element to true as Example 15-5 shows.

    Example 15-5 Creating a debug-properties Element for the Debug Flag

    <config>
       <debug>
          <debug-properties>
             <DebugSDS>true</DebugSDS>
          </debug-properties>
       </debug>
    
    </config>
    
  6. Set logger-severity to Debug in the logging-service element as Example 15-6 shows.

  7. 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>