finally I found the bug. This is the reason. In rampart before doing any processing it creates an envelop of the original soap envelop. in this process it does not copy the isProccessed attributes set in the SoapHeaderBlock. As a result of this if the isProcessed atribute is set then after this process again it set to false.
in the AddressingInhadlers it process Header Blocks and set the attributes. So if we have Security after the addressing, those is processed attributed set by the AddressingInHadlers is set to false and this gives an exception at the checkMustunderstand method. I have fixed this by changing the phases. i.e. security come before addressing. When cosidering this senario I see some advantage of setting this flag. Although there is no problem with the addressing. We can swith on the mustunderstand in client side using client options but can not think a way in server side. (when sending the request) Amila. On 6/4/07, Jaliya Ekanayake <[EMAIL PROTECTED]> wrote:
Hi Amila and Eran, I also don't think that axis2 should set mustunderstand to all the headers unless it is required by the application. For e.g. say a client needs to inform the server that it should understand the <wsa:Action> by setting mustunderstand =1 for wsa:Action. So if the server does not process the wsa:Action a fault should be generated. From the receiving side, each module implementation should check the mustunderstand property and "understand" it(we have this right now) but I am not sure whether we can set the mustunderstand property for specific SOAP headers by the axis2 client. Thanks, -jaliya ----- Original Message ----- From: "Eran Chinthaka" <[EMAIL PROTECTED]> To: <axis-dev@ws.apache.org> Sent: Saturday, June 02, 2007 9:35 PM Subject: Re: Setting must understand property true for all required attributes in addressing > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Amila, > > Can you please explain what this issue is? Our current addressing code > passed all the test case during the last interop. IIRC, there were tests > to see whether we understand those required properties (please see > defined set of problems in [1]). > > So I assume we are good in terms of the spec. We can not simply change > something because MSFT is doing that or any other company is doing that. > I hate doing so. For example, when we send a request with ReplyTo set to > NONE, one implementation was sending the response using the same channel > that we use to send the request, which is completely wrong. If you want > I can give you some more examples that some of the companies were doing > without adhering to the specs. > > So please explain what the problem is and if it is something that we are > doing wrong then let's fix it. You will have to point to the spec and > not to any proprietary implementation please. > > Thanks, > Eran Chinthaka > > [1] : http://www.w3.org/TR/ws-addr-soap/#soapfaults > > Amila Suriarachchi wrote: >> hi, >> Currently, the must understand property of the addressing headers do not >> set for the >> required addressing headers. There is no problem with this, since there >> is no compulsory requirement for that. >> But MS implementation of WS* (WSF) set these attributes. >> Therefore sometimes we get interop issues when processing the must >> understand properties. So setting >> must understand property true within the Axis2 would resolve these >> incompatibility issues easily. >> >> So shall we switch on the must understand property for all the required >> addressing headers if there is no >> reason for not to do so. >> I think it is better to do the same thing for rampart and sandesha too. >> >> if we decide to do so can someone go ahead and do the changes since I am >> not >> much familiar with the addressing. >> >> thanks, >> Amila. >> >> >> -- >> Amila Suriarachchi, >> WSO2 Inc. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGYhrdjON2uBzUhh8RAlwpAJ4zToh2QACxCRoT/ByHVIwvO6rkmACfT65u > WDsFB1pmShG43jf2VvIBj7M= > =uGgM > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Amila Suriarachchi, WSO2 Inc.
