synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (JIRA)" <j...@apache.org>
Subject [jira] Created: (SYNAPSE-374) Simplify the way logging is done in mediators
Date Tue, 24 Jun 2008 22:55:45 GMT
Simplify the way logging is done in mediators
---------------------------------------------

                 Key: SYNAPSE-374
                 URL: https://issues.apache.org/jira/browse/SYNAPSE-374
             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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org


Mime
View raw message