{section}
{column}

h1. Logging systems

Petals ESB uses two distinct logging systems. Most of the container apart from the registry uses the logger provided by the JDK, while the registry uses Apache log4j.

The Petals ESB logger configuration is splitted into two files, one for each logging system:
* the JDK Logging system is configured according to the following ordered rules:
*# the file defined as value of the Java system property {{petals.container.log.config.file}} to set on the Java command line,

{note}An issue JIRA already exists to merge both logging systems: {jira:PETALSESBCONT-227}{note}

Each property value of the JDK logging system configuration file can contain reference to other properties using a placeholder as:
{code}org.ow2.petals.log.handler.PetalsFileHandler.basedir=${petals.log.dir}{code}
Available properties to use as placeholder are:
* the system properties including all properties defined on the java command line using the flag '{{-D}}',
* the properties of the container configuration file, ie. {{server.properties}}.

{column}
{column:width=350px}
{panel:title=Table of contents}{toc:outline=true}{panel}
{panel:title=Contributors}{contributors:order=name|mode=list|showAnonymous=true|showCount=true|showLastTime=true}{panel}
{column}
{section}

h1. Petals Logging specificities

{tip}You can find more informations about few concepts mentioned below in glossary [Glossary|http://doc.petalslink.com/display/glossary/Petals+ESB+specific+vocabulary].{tip}

h2. Level 'MONIT'

Petals defines a new specific level: MONIT. This level is used to [trace the process activities and permit to deduce the process execution launched by an initial request|Monitoring Petals ESB Flows with its logs].

The level MONIT is inserted between levels CONFIG and FINE:
* SEVERE (highest value)
* WARNING
* INFO
* CONFIG
* *MONIT*
* FINE
* FINER
* FINEST (lowest value)

This new level comes with dedicated information. So, to be printed, a new formatter was created: [{{org.ow2.petals.log.formatter.LogDataFormatter}}|#petals_formatter]. This formatter can be used with standard handlers as {{java.util.logging.ConsoleHandler}}.

To trace exchange activities into files, it is better to have a policy based on one log file per process instance instead of having one big file. One file by process instance is more human readable. So a new file handler is also provided: [{{org.ow2.petals.log.handler.PetalsFileHandler}}|#petals_file_handler].

The MONIT level permits also to dump the message exchange content using another dedicated file handler: [{{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}}|#petals_dumper_file_handler]. It is based on the file handler '{{org.ow2.petals.log.handler.PetalsFileHandler}}' adding it dump capabilities.

h2. Default levels

The default root logger level is WARNING. It means that all classes log only SEVERE and WARNING information.

The default Petals root logger level is INFO. That's why all Petals components will log only SEVERE, WARNING and INFO information.

The default components level is MONIT.

You can enable logging and specify a specific level for each module (container, component, cdk...). Here is how you would set debugging from Petals. You would need to ensure the Handler's level is also set to collect this threshold, so FINEST or ALL should be set.
{code}
##Petals level
Petals.level = FINEST

#Handler Configuration
java.util.logging.ConsoleHandler.level = FINEST
{code}

Example of configuration to debug (Level FINEST) petals-bc-soap component:
{code}
##Petals level
Petals.level = INFO #Log level for all petals services
Petals.Container.Components.level = MONIT #log level for all components
Petals.Container.Components.petals-bc-soap.level = FINEST #Log level for petals-bc-soap component

#Handler Configuration
java.util.logging.ConsoleHandler.level = FINEST
{code}

{anchor:petals_formatter}
h2. Petals formatter

The Petals formatter {{org.ow2.petals.log.formatter.LogDataFormatter}} is used for both standard traces of the Petals ESB container and process activity traces. The format of the logged message is :
{panel:borderStyle=solid}+Petals Node Name+ +YYYY/MM/DD+ +HH:MM:SS,FFF+ +GMT+ +LOG LEVEL+ [+LOGGER NAME+] : +LOG MESSAGE+{panel}
For a process activity, the log message is composed of several fields as key/value depending on the JBI component and activity. See [Monitoring Petals ESB Flows with its logs] for more information on fields.

*Example of logging output with the Petals formatter:*
{code}
sample-0 2013/03/07 10:31:31,084 GMT+0100 INFO [Petals.Communication.RMIConnector] : JMX RMI server started at : service:jmx:rmi:///jndi/rmi://localhost:7700/jmxRmiConnector
...
sample-0 2013/03/07 10:31:32,459 GMT+0100 MONIT [Petals.Container.Components.petals-bc-soap] : traceCode = 'consumeFlowStepBegin',flowInstanceId = '62cdea40-cf20-11e0-bdfa-000c29523cc7',flowStepId = '62ce3860-cf20-11e0-bdfa-000c29523cc7',flowInterfaceName = '{[http://usecase1/bpel-P12/]}interfaceName1',flowServiceName = '{[http://usecase1/bpel-P12/]}serviceName1',flowEndpointName = 'endpointName1',flowOperationName = '{[http://usecase1/bpel-P12/]}process',client = '192.168.1.157',requestedURL = 'http://192.168.1.196:8084/petals/services/soap-C1'
{code}

{anchor:petals_file_handler}
h2. Splitting log files

Petals ESB allow to split its log records into a log files hierarchy. This is done thanks to the Petals file handler '{{org.ow2.petals.log.handler.PetalsFileHandler}}' which can redirect log records to separate files according to their nature:
* if the log record is generated into a process activity context, it is redirected in the log file dedicated to the process instance,
* otherwise, the log record is sent into the global log file.

{anchor:log_file_hierarchy}
The default log files hierarchy is the following one:
* basedir
** petals.log: The global log file in which log records that are not generated into a process activity context are logged,
** flow-monitoring: Directory in which log files of log records associated to process activities are written,
*** <uid>: Directory of log files associated to the activities of only *ONE* process instance,
**** petals.log: The log file of process activities of only *ONE* process instance.

In addition to the standard properties ({{level}} and {{formatter}}), the specific configuration properties of the Petals file handler are:
* {{basedir}}: The absolute root directory of the log file hierarchy. The default value is the value of the system property '{{petals.log.dir}}',
* {{flows-subdir}}: The name of the directory contained in the {{basedir}} where log files of log records associated to process activities are written. Default value: {{flow-monitoring}},
* {{logFilename}}: The name of log files. Default value: {{petals.log}}.

{anchor:petals_dumper_file_handler}
h2. Debuging process execution

In the previous paragraph, you see how to get traces about process instance executions. For a debugging or replaying purpose, it is interresting to get the content of messages exchanged. This is possible using another Petals file handler: {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}} based on the previous file handler {{org.ow2.petals.log.handler.PetalsFileHandler}}.

The content of the messages are dumped in the log files hierarchy defined [above|#log_file_hierarchy] in the directory dedicated to the current process instance. One dump file is created for each message sent or received containing its XML payload.

This Petals file handler has the same configuration properties than its [parent|#petals_file_handler].

{note}An issue JIRA already exists to dump the whole content of messages, including properties and attachments: {jira:PETALSESBCONT-228}{note}

h2. Using your own log handler

If you want redirect the MONIT traces elsewhere than into log files, you can use your own log handler. Just put its JAR file and dependencies into the Petals library directory, and configure you log handler into the configuration log file.