Hi All..
I was discussing with Paul on this, and he was of the view that we
should keep the interfaces as simple as possible without making them any
more complex - and he convinced me. So it seems like I have a solution
to fix the problem - without any changes required. Actually I can clean
up the interface even more as it stands right now :-) .. but give me
some time until I finish trying this out and committing the code for review.
thanks to all for the patience and the comments you shared with me
asankha
Ruwan Linton wrote:
+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 ????
Thanks,
Ruwan
On 9/21/07, Asankha C. Perera <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
