synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "indika priyantha kumara (JIRA)" <>
Subject [jira] Commented: (SYNAPSE-374) Simplify the way logging is done in mediators
Date Wed, 25 Jun 2008 07:32:45 GMT


indika priyantha kumara commented on SYNAPSE-374:

Separating logging concern is good .

I feel that 'SynapseLog' should be a composite one. We have to hide the fact that there are
multiple loggers(service logs,trace,class...) are there in the code level and only it (There
are multiple loggers) should enforce through a configuration file.( It really
preserves the encapsulation.

auditLog(String msg,SynapseLog servicelog,SynapseLog traceLog) is bad and it really reveals
 that within 'auditLog' method both 'servicelog' and ' traceLog' are going to be used. This
breaks the encapsulation as it reveals the internal about 'auditLog' method. In additions,
if the log categories are going to be large  and if we have to pass those as an arguments
to the method, API will be worse. 

I purpose a composite class for 'SynapseLog' implementation or itself. Then use a factory
method to construct this 
 getLog(MessageContext msgContx,String className);

This method should return a composite which contains all the log categories that have been
enabled. (Example- if trace is enable , tracelog is there as a child , otherwise it will not
be there). Then when invoking a method on root , it delegated it to children. 

isXXXEnable() kind of method may return true if there is a at least log ('SynapseLog') that
returns 'true'  indicating there is at least one log interesting in receiving log messages.
debug() kind of method call over the all registered log category classes if there any. 

if we just use common-log and if we never want to expose the abstraction related to synapse
(Ex : auitWarn()) then we can make 'SynapseLog' is a composite class which implements the
common-log interface.


> Simplify the way logging is done in mediators
> ---------------------------------------------
>                 Key: SYNAPSE-374
>                 URL:
>             Project: Synapse
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: NIGHTLY
>         Environment: N/A
>            Reporter: Andreas Veithen
> Mediators can log messages to three different logs: the usual log with category set to
the class name, the trace log and the service log. While this is extremely useful and should
be preserved, the way mediators have to be coded to leverage these logging facilities could
be improved. Indeed the following problems with the current situation can be identified:
> * Code using the logging methods defined in AbstractMediator can't be reused in anything
else then mediators. A random example is the SpringMediator#buildAppContext method. The code
in this method can quite easily be reused in another mediator (provided that both mediators
have a common base class) but not e.g. in a Startup implementation. The reason is that it
uses the traceOrDebug method from AbstractMediator.
> * In general, when the code in a mediator is split into several methods or when reusing
a method in several mediators, it is required to pass traceOrDebugOn and traceOn from one
method to the other. This is quite annoying.
> * For someone who starts writing new mediators it is not obvious how to correctly use
the various logging methods. In addition, the current implementation doesn't enforce a consistent
use of the logging facilities, one of the reasons being that the log and trace attributes
in AbstractMediator are accessible to subclasses. E.g. there are mediators that simply call
log.error, thereby bypassing the TRACE and SERVICE logs.
> To improve the situation, the proposal is to:
> (1) Introduce an interface called SynapseLog with
> * a set of logging methods such as error, info, traceOrDebug, auditWarn, etc. (mainly
equivalent to what is defined now in AbstractMediator);
> * a set of corresponding isXxxEnabled methods following the pattern in commons-logging.
> (2) Add a getLog(MessageContext) method to AbstractMediator that returns an appropriate
implementation of the SynapseLog interface. Mediator implementations would call this method
at the beginning of the mediate method and exclusively rely on the returned object to send
messages to the logs. If the code in the mediator is split into several methods or if it shares
a common method with another mediator, this object would be passed as argument to these methods
(instead of traceOrDebugOn and traceOn).
> (3) Create a SynapseLogAdapter class that implements SynapseLog and that delegates calls
to a single org.apache.commons.logging.Log instance. Instances of this class would be used
by code that is executed outside of a mediator but that needs to call a method shared with
some mediator implementation.
> To summarize, the general idea is to expose a set of (Synapse specific) logging categories
in a well defined interface and to completely hide the underlying implementation(s) behind
this interface. Note that the proposal can be implemented without breaking any existing code:
it can coexist with the existing logging methods in AbstractMediator which would later be
tagged as deprecated before potentially being removed in some future version of Synapse.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message