This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Status Update

Following on from the high level design, this page will provide a more detailed design approach to implement status update logging in the Java broker.

The logging hierarchy identified in the high level design is not suitable to be directly used by Log4j as there is multiple routes and loops in the graph.

To better address this and to allow us to more eaily move between logging implementations an abstraction is recommended. This approach will allow the simplification of the logic around determining if logging should be performed in the main code base.
For example a Binding logging statement can be controlled via Exchange and Queue, each of which may be limited to s specific instance.

This design will cover the following areas:

  • Logging Abstraction
  • Logging Control
  • Logging Usage

Logging Abstraction

Logging Control

Logging Usage

Status Logging
pubic class Subscription
...
    if (_statusLogger.isInfoLogEnabled(this))
    {
        _statusLogger.info(this, "Subscription Event occured.");
    }
...

Would result in the following based on the Logging Format Design.

2009-06-29 13:35:10,1234 +0100 [ con:1(guest, 127.0.0.1, /)/ch:2/[sub:1(myqueue) ] Subscription Event occcured.
Plugin Logging
pubic class Channel
...
    plugin = getACLPlugin();
...
    if (_statusLogger.isInfoLogEnabledForPlugin(plugin, this))
    {
        _statusLogger.pluginInfo(plugin, this, "Plugin Event occured for this.");
    }
...

Would result in the following based on the Logging Format Design.

2009-06-29 13:35:10,1234 +0100 [ con:1(guest, 127.0.0.1, /)/ch:2/pl(ACL, Consume, qu(myQueue)) ] Plugin Event occured for this. 
  • No labels