You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Andreas Veithen (JIRA)" <ji...@apache.org> on 2008/06/25 00:55:45 UTC
[jira] Created: (SYNAPSE-374) Simplify the way logging is done in
mediators
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
[jira] Commented: (SYNAPSE-374) Simplify the way logging is done in
mediators
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-374) Simplify the way logging is done in
mediators
Posted by "indika priyantha kumara (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607878#action_12607878 ]
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.(log4j.properties). 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.
Thanks
Indika
> 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
[jira] Commented: (SYNAPSE-374) Simplify the way logging is done in
mediators
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608071#action_12608071 ]
Andreas Veithen commented on SYNAPSE-374:
-----------------------------------------
I added the SynapseLog interface, a concrete MediatorLog implementation and a factory method in AbstractMediator. I also changed SendMediator to use the new facilities. This should give everyone an idea about what the new logging code will look like.
Some comment:
* MediatorLog doesn't include the service log yet since this is only used by the existing auditLog, auditWarn and handleException methods in AbstractMediator and there are no corresponding methods defined yet in SynapseLog.
* Obviously the names of the log levels defined in SynapseLog are a bit ugly (e.g. traceTrace) but this has the advantage that the existing code can be migrated easily (traceTrace essentially replaces trace.trace). We can agree later on more convenient names and do a refactoring.
> 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
[jira] Commented: (SYNAPSE-374) Simplify the way logging is done in
mediators
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607887#action_12607887 ]
Andreas Veithen commented on SYNAPSE-374:
-----------------------------------------
Indika,
Concerning the encapsulation aspect, I think we completely agree with each other: the fact that there are trace and service logs should be completely hidden from the mediator implementations. E.g. the signature of the auditLog method in SynapseLog should be simply auditLog(String) with no additional arguments.
Your last point is interesting. Actually there are three options:
(1) Having a SynapseLog interface with Synapse specific log levels (not categories as I incorrectly wrote in my proposal) and not extending any existing interface. This is the original proposal.
(2) Having a SynapseLog interface extending Log (from commons-logging) and defining additional log levels.
(3) Not having a SynapseLog interface at all and encapsulate the 3 logs behind an implementation of the Log interface. This would completely remove the need for a SynapseLogAdapter.
The basic question is whether we have enough with the log levels defined in the Log interface. Actually the decision on which of the three options to use is not so urgent. Indeed one can go from option to the other by a rather simple refactoring. Thus we don't need to decide that immediately, but only before the next release. I would propose to start with option (1) and later see in practice to what extend we can map the log levels to the standard ones defined by commons-logging.
> 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
[jira] Commented: (SYNAPSE-374) Simplify the way logging is done in
mediators
Posted by "indika priyantha kumara (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607896#action_12607896 ]
indika priyantha kumara commented on SYNAPSE-374:
-------------------------------------------------
Andreas
Your suggestion is good. when I am reading (2) part of your original proposal,I just felt , we will not be able to hide completely the fact that there are different log (trace.service).
"(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).*** "
Therefore, I thought using a composite pattern we can hide those properly.
Thanks
Indika
> 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
[jira] Resolved: (SYNAPSE-374) Simplify the way logging is done in
mediators
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Veithen resolved SYNAPSE-374.
-------------------------------------
Resolution: Fixed
Fix Version/s: 1.3
* All core and extension mediators have been updated to use the SynapseLog interface.
* Old logging methods in AbstractMediator have been deprecated.
> 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
> Assignee: Andreas Veithen
> Fix For: 1.3
>
>
> 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
[jira] Commented: (SYNAPSE-374) Simplify the way logging is done in
mediators
Posted by "Ruwan Linton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607834#action_12607834 ]
Ruwan Linton commented on SYNAPSE-374:
--------------------------------------
Very interesting and I am for it
+1 for the proposal
> 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
[jira] Assigned: (SYNAPSE-374) Simplify the way logging is done in
mediators
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andreas Veithen reassigned SYNAPSE-374:
---------------------------------------
Assignee: Andreas Veithen
> 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
> Assignee: 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