[
https://issues.apache.org/jira/browse/SYNAPSE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607851#action_12607851
]
Asankha C. Perera commented on SYNAPSE-374:
-------------------------------------------
Yep.. very interesting indeed...!
+1 asankha
> 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]
