Hi Asankha and Eric, I also think the default value of the markAsResponse field has to be true and I will change that. For the second question, that is to check the ReplyTo for the presence and remove the To header if it is not present is a redundant work, here is the explanation for that :-)
When we use the configuration to set the To header with the ReplyTo header, if the ReplyTo header has not been set, then it returns null and on the configuration this will lead to a String "null" being set as the To header which in-turn causes a malformed URI exception. There for when we use the configuration language to do this you need to check the presence of the ReplyTo header and copy it as the To header if there is a one and should remove the To header to make it null if there is no ReplyTo. But, programatically null (not string "null") being set as the To header (When the ReplyTo header is not there this is the case) is same as removing the To header. There for the existing code is doing what is expected. So one line change of - private boolean markAsResponse = false; + private boolean markAsResponse = true; would fix all these. At the same time I think the FaultMediator has to be aware of addressing specification and should consider the existence of FaultTo header as well, because this is a fault according to WS-Adressing, if there is a wsa:FaultTo header, then the fault has to be sent to the specified address but not to the ReplyTo address nor on the same channel. Thanks, Ruwan On Fri, Aug 1, 2008 at 12:18 PM, Hubert, Eric <[EMAIL PROTECTED]> wrote: > Hi, > > > > yes, marking a fault as a response by default sounds also reasonable to me. > If there are really cases where this is not what you want, you can simply > leave the code as it is, but just initialize the markAsResponse to true by > default so the user would only need to configure something if he wants to > change the default to not send the fault as a response. > > > > Removing the To header programmatically here if no ReplyTo exists sounds > like a good idea. This would further reduce the need of configuration. > > > > Good ideas Asankha, I'm also interested whether Ruwan has some cases in > mind, where this would not be a desired behaviour. > > > > > > Regards, > > Eric > > > ------------------------------ > > *From:* Asankha C. Perera [mailto:[EMAIL PROTECTED] > *Sent:* Friday, August 01, 2008 8:12 AM > *To:* dev@synapse.apache.org > *Subject:* Re: svn commit: r672650 - in > /synapse/trunk/java/modules/core/src: > main/java/org/apache/synapse/config/xml/ > main/java/org/apache/synapse/mediators/transform/ > test/java/org/apache/synapse/config/xml/ > > > > Ruwan > > I think by default, we should mark a fault as a response? Any reason to not > do this? > > Also for the below code, shall we check if a ReplyTo exists, and else > remove the 'To' header like we now do in config? > > thanks > asankha > > [EMAIL PROTECTED] wrote: > > Author: ruwan > > Date: Sun Jun 29 10:33:49 2008 > > New Revision: 672650 > > > > Fixing the issue SYNAPSE-367 > > > > now the <makeFault> will optionally mark the message as a response when the > response attribute value is set to true > > > > ============================================================================== > > --- > synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/mediators/transform/FaultMediator.java > (original) > > +++ > synapse/trunk/java/modules/core/src/main/java/org/apache/synapse/mediators/transform/FaultMediator.java > Sun Jun 29 10:33:49 2008 > > @@ -114,23 +118,31 @@ > > ... > > + // if the message has to be marked as a response mark it as response > > + if (markAsResponse) { > > + synCtx.setResponse(true); > > + synCtx.setTo(synCtx.getReplyTo()); > > + } > > + > > + return true; > > > > > > -- > Asankha C. Perera > > WSO2 - http://wso2.org > http://esbmagic.blogspot.com > -- Ruwan Linton http://wso2.org - "Oxygenating the Web Services Platform" http://ruwansblog.blogspot.com/
