Unified trace management - introduction

Unified trace management is based on:

• the slf4j Framework (configured by default with the log4j2 binding) for the Java platform (Java – Web – Cloud) and

• the log4c Framework for the C/Windows and AS/400 platforms.

Trace management is used to gather information relating to the execution of applications generated with Adelia Studio.

This information may come from:

• Adelia execution runtimes (DB queries, information exchange by the middleware, etc.),

• the generated programs (information internal to the generator or information from generating the ADD_TRACE instruction),

• third-party application libraries (frameworks in charge of the consumption or production of web services for example).

The aim of trace management is to gather information:

• to ensure, after the event, that an execution has been properly performed

• to understand the reasons for dysfunctional execution.

The trace management frameworks mentioned above implement the following three components:

• Layout: message formatting.
  See the example configuration files for the list of "layout" components and usable designs for formatting.

• Appender: receives messages (message storage target).
  See the example configuration files for the list of available "appender" components.

• Category or Logger: association between a message issuer, a severity level and one or more "appender" components. The possible levels, presented in decreasing order of severity, are:

o FATAL

o ERROR

o WARN

o INFO

o DEBUG

o TRACE

A message is issued by a "logger" if and only if its severity level is equal to or higher than that of the "logger".

For example, a DEBUG-level message is not handled by a "logger" configured with the ERROR level.

However, an ERROR-level message is sent to all the "appender" components associated with the "logger" configured with the "DEBUG" level.

Together the three components are used to issue messages in a certain format to different storage targets.

"Category" or "logger" components are prioritised by their name, using a legacy system: the use of '.' in the name delimits a level in the hierarchy. For example, a "logger" called "com.hardis.adelia" inherits properties from the "logger" called "com.hardis".

All the "logger" components inherit from the "logger" called "Root" for log4j2 and "root" for log4c.

A "logger" component inherits its parent's severity level.

A "logger" component inherits its parent's "appender" components. By setting the "logger" component's "additivity" property to "false", it is possible - if necessary - to avoid inheriting the "appender" components.

The different trace messages come from Adelia execution runtimes, the generated programs or third-party application libraries.

Adelia language enables the user's own traces to be added to the mechanism using the ADD_TRACE instruction. The latter is used to issue a message in a specific severity level for the default "logger" (that associated with the program) or for a specific "logger", the name of which is chosen by the user.

    <dependencies>
        <dependency>
            <groupId>com.hardis.adelia</groupId>
            <artifactId>adelwagon</artifactId>
            <exclusions>  
                <exclusion>  
                    <groupId>org.apache.logging.log4j</groupId>
                    <artifactId>*</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
            <version>1.2.10</version>
        </dependency>       
        ...

configurations.all {
    exclude group: 'org.apache.logging.log4j'
}

dependencies {
    runtime group: 'ch.qos.logback', name: 'logback-classic', version: '1.2.10'
    ...
}

Click her for more information on the trace production configuration.

↑ Top of page