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