synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruwan Linton" <>
Subject Re: Refactoring Tracing and Logging
Date Fri, 21 Sep 2007 14:28:30 GMT
+1 for this Asankha.

Shall we cleanup all the interfaces before 1.1 release so that we can live
with the core API without doing frequent API changes. I have also done an
API change in the SynapseEnvironment#injectMessage.

Any more API changes that we need to do to cleanup our API ????


On 9/21/07, Asankha C. Perera <> wrote:
> 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);
> thanks
> asankha
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Ruwan Linton - "Oxygenating the Web Services Platform"

View raw message