Sorry I should have replied on the list!!!! Basically I think that this is an "aspect" (as in AOP programming) that we should try to keep out of the interface. The reason I didn't reply on the list was because I didn't have a good idea how.... but it seems like Asankha may have figured it out... my fingers are crossed :)
Paul On 9/22/07, Asankha C. Perera <[EMAIL PROTECTED]> wrote: > 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] > >> > >> > >> > > > > > > > -- Paul Fremantle Co-Founder and VP of Technical Sales, WSO2 OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
