Tracer Interface

In SLEE 1.1, there are more components that may need tracing support. In addition to SBBs, trace messages may also be generated by profile abstract classes and resource adaptors, and potentially any other SLEE subsystem.

All of these components may use the SLEE 1.1 javax.slee.facilities.Tracer interface. The Tracer interface will be familiar to users of other logging APIs. It provides methods for generating traces at different trace levels. Details of the tracing methods available are in the javax.slee.facilities.Tracer javadoc.

Obtaining a Tracer

Components obtain Tracers by calling the getTracer() method on the particular component’s context object. Rhino 2.6 provides 'com.opencloud.rhino.facilities.ExtendedTracer' instances when acquiring a Tracer, If only Rhino 2.6 support is required, the Tracer acquired from a context may be safely cast to ExtendedTracer

Older Rhino versions provide a com.opencloud.rhino.facilities.Tracer. The older Rhino implementation does not offer the extended logging API that the ExtendedTracer does.

For backwards compatibility Rhino 2.6 API library contains a com.opencloud.rhino.facilities.trace.TracerAccessor which handles safely acquiring a Rhino 2.6 ExtendedTracer.

Table 1. Example Tracer acquisition
Component Tracer access method

SBB

 
 ExtendedTracer trace = (ExtendedTracer)SbbContext.getTracer(String)

Profiles

 
ProfileContext.getTracer(String)

Resource Adaptors

 
ResourceAdaptorContext.getTracer(String) or TracerAccessor.getExtendedTracer(ResourceAdaptorContext, String)

The string parameter in the above methods is the tracer name. This is a hierarchical name, following Java naming conventions, where the different levels in the hierarchy are delimited by a dot. For example, a tracer named "com.foo" is the parent of "com.foo.bar". Components may create any number of tracers, with different names, for different purposes. Tracers inherit the trace level of their parent in the hierarchy. The tracer named "" (empty string) is the top-level or root tracer. The hierarchical naming is a convention used in most logging APIs, and allows an administrator to easily enable or disable tracing for an entire hierarchy of tracers.

Example
import javax.slee.Sbb;
import javax.slee.SbbContext;
import javax.slee.facilities.Tracer;

public abstract class MySbb implements Sbb {

    private Tracer rootTracer;
    private ExtendedTracer fooTracer;
    private SbbContext context;

    public void setSbbContext(SbbContext context) {
        this.context = context;
        this.rootTracer = context.getTracer("");
        this.fooTracer = (ExtendedTracer)context.getTracer("foo");
    }

    ...

    // Generate an INFO trace on the root tracer
    rootTracer.info("An event has occurred");
    ...

    // Generate a WARNING trace on the fooTracer
    fooTracer.warning("Could not combobulate {}", "discombobulator");

Notification Sources

SLEE 1.1 introduces the javax.slee.management.NotificationSource interface, which the SLEE automatically adds to notifications generated by SLEE tracers. As this is automatically asssociated with the Tracer object, there is no need to manually specify source as in SLEE 1.0. This solves the problem of identifying which SBB in which service generated a trace message. The NotificationSource explicity identifies the component that generated the trace, so a management client can easily see which service and SBB the trace came from, allowing filtering by service or SBB.

Tracer Extensions

To alleviate some limitations of the SLEE 1.1 Tracer system, Rhino offers an extended Tracer API. This extended API offers a larger set of tracing methods, to support tracing without string concatenation to build trace messages. Tracer extensions contains details of the Tracer API extensions, and com.opencloud.rhino.facilities.ExtendedTracer javadoc is available.

Rhino 2.6 Tracer Extensions

In Rhino 2.6, the Tracer subsystem has been substantially reworked. As a result, Tracers are now first class loggers. This means that a Tracer may be manipulated by logging management commands as if it were a logger, with the exception that it will only accept Tracer levels.

Tracers now have very long logger names, as they must be unique to support making Tracers first class loggers. In log files these very long names are inconvenient, as they will frequently cause log entries to run over multiple lines on screen. In order to alleviate this issue, we have included a default tracer name abbreviation system.

Tracer pattern converter

The Tracer abbreviator used by default is based heavily on the logger pattern converter supplied with Log4j 2. See Log4j 2 Pattern Layout for documentation.

The tracer pattern converter shipped with Rhino allows for optionally completely removing a logger/tracer name component. In contrast, the logger pattern converter will always leave a . literal to show where elements have been abbreviated. The tracer pattern converter also does not implement Log4j 2 integer precision abbreviation, only pattern abbreviation.

Tracer name Pattern Output

trace.default.resourceadaptorentity.simplera.example

 
 %logger{\*.0.0.*}
 
 trace...simplera.example

trace.default.resourceadaptorentity.simplera.example

 
 %tracer{\*.0.0.*}
 
 trace.simplera.example

Tracer abbreviation behaviour can be managed through REM or by editing an exported logging.xml.

The default tracer pattern converter shipped with Rhino is shown below

Default tracer pattern converters
<component plugin-name="MarkerPatternSelector" >
  <property name="defaultPattern" value="%d{yyyy-MM-dd HH:mm:ss.SSSZ} %-7level [%logger] &lt;%threadName&gt; %mdc %msg{nolookups}%n%throwable"/>
  <component plugin-name="PatternMatch">
    <property name="key" value="Trace"/>
    <property name="pattern" value="%d{yyyy-MM-dd HH:mm:ss.SSSZ} ${plainLevel} [%tracer{*.0.0.*}] &lt;%threadName&gt; %mdc %msg{nolookups}%n%throwable"/>
  </component>
  <component plugin-name="PatternMatch">
    <property name="key" value="SbbTrace"/>
    <property name="pattern" value="%d{yyyy-MM-dd HH:mm:ss.SSSZ} ${plainLevel} [%tracer{*.0.0.*.0.*.*.0.0.*}] &lt;%threadName&gt; %mdc %msg{nolookups}%n%throwable"/>
  </component>
</component>

Note that there are three patterns in use here.

Marker Pattern Usecase

None (defaultPattern)

 
 %logger

Used for non-tracer log messages

SbbTrace

 
 %tracer{\*.0.0.*.0.\*.*.0.0.*}

Used for Tracer messages logged from an SBB.

Trace

 
 %tracer{\*.0.0.*}

Used for Tracer messages logged from anything other than an SBB

Different patterns are required for SBB and non-SBB Tracers, due to the more complex notification source identity of SBB notification sources. An SBB notification source includes both SBB id and Service ID. All other notification sources have no equivalent of Service ID.

Previous page Next page
Rhino Version 3.2