Brian Reinhold created AXIS2-5447:
-------------------------------------
Summary: WS-Addressing 'mustUnderstand' attribute not generated in
response
Key: AXIS2-5447
URL: https://issues.apache.org/jira/browse/AXIS2-5447
Project: Axis2
Issue Type: Bug
Components: Addressing
Affects Versions: 1.6.2
Environment: Windows7 32-64 Tomcat 28 and 30
Reporter: Brian Reinhold
A: Description of Problem:
When sending a message containing WS-Addressing elements with the
mustUnderstand attribute set to
'true' or '1', the response does not contain the attributes.
B: Discussion:
It is not entirely clear from the SOAP specification WHAT the response
should be. In the brief section that
it is discussed, the request and response shown both have the
mustUnderstand attribute set. Nowhere
that I can find do I see a statement saying the attribute MUST be present
in the response if the request
has it, however I assume so based upon the example.
Also, it is not clear if the mustUnderstand is 'global'; that is if one
WS-Addressing element has it, they all
are assumed to have it. That is of interest because the way the current
In/Out handlers and
mustUnderstand checkers work, it is assumed to be global. There is a
mustUnderstand property that
when true will cause the mustUnderstand attribute to be added to all
WS-Addressing elements and set
to true.
C: Workaround:
In the In-handler I check for the existence of the mustUnderstand attribute
and if it is present and set to
true, I set the messageContext property indicating that the request has a
mustUnderstand=true setting.
That property causes the Out handler to generated the attribute in the
response (in all elements).
I do NOT know if that is the intended design.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
