synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <>
Subject Refactoring Tracing and Logging
Date Fri, 21 Sep 2007 09:11:26 GMT
Hi all

I am in the process of refactoring trace and log messages so that we are 
able to perform real enterprise grade logging and great tracing of 
messages through mediation. I am also introducing the concept of a 
"service" level log - as suggested by some of our users. Thus users 
would be able to either direct all service log messages to a single 
appender, or create multiple appenders for each proxy service etc. The 
service logs will function as an audit log - i.e. they will report if a 
service was started, stopped, encountered a warning, or error etc. so 
that sysadmins and other monitoring tools can safely monitor important 
services for such activity

Tracing will be enhanced such that one could follow the trace of a 
message through mediation. However in future the trace level could be 
configured via log4j as well. Thus typically trace messages will appear 
at INFO level on the *trace* logs and would correspond with the DEBUG 
level developer logs on the level of information they provide. However 
if the trace level is set to TRACE, it will capture the complete SOAP 
message, or the full WS-Policy etc and be at its 'most' 
informative/verbose level - so that a problem is much easier to 
understand and resolve - even remotely.

Ok.. now comes the section where I explain why I am going to add a new 
method to the 'Mediator' interface :-) ! Currently if I had sequences 
S1, S2 and S3 and S1 calls S3 as well as S2 calls S3, if I had enabled 
tracing at S1, the messages are traced as they pass through S2 as well. 
(i.e. since S2 doesn't specify anything but the parent S1 did) Now if S3 
said not to trace, we still would trace a message from S3 through S2 as 
we used an instance variable to keep track of tracing on S2 - which is 
wrong and a bug.

So I am going to introduce a new method to the Mediator interface as 
follows, and implement a backwards compatible implementation on the 
AbstractMediator, which will ensure that [hopefully] 95% of any 
mediators that others have written would continue to work without 
problems - if they inherited from the AbstractMediator - which I believe 
is the case for most of the custom mediators today. However, I wanted to 
let the list know of this before I go ahead and commit the changes, and 
hope that all of you would agree that this is the right thing to do!

public boolean mediate(MessageContext synCtx, boolean parentsTraceOn);


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

View raw message