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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
