[
https://issues.apache.org/jira/browse/AXIS2-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468482#comment-13468482
]
Brian Reinhold edited comment on AXIS2-5431 at 10/3/12 10:17 PM:
-----------------------------------------------------------------
I have done some further work on this problem but I do not know if it is
correct. In the In-handler (in the addressing module) I added code to check for
the mustUnderstand attribute and if it is found and true (or 1) I set the
property to indicate that it has the mustUnderstand. In the creation of the
outbound message in the MessageContextBuilder I add this line of code
newmsgCtx.setProperty(AddressingConstants.ADD_MUST_UNDERSTAND_TO_ADDRESSING_HEADERS,
inMessageContext.getProperty(
AddressingConstants.ADD_MUST_UNDERSTAND_TO_ADDRESSING_HEADERS));
These two changes create the missing attribute in the addressing headers. (I am
not saying this is correct for the Axis2 model because I do not understand its
scope very well at this time; however I want to see if that would solve the
client side error.) However, in spite of the presence of the attributes, the
error STILL comes up. The reason turns out NOT to be on the addressing headers
but in the security header. Though the security header HAS the mustUnderstand
attribute, it apparently has NOT been 'registered' with JAXWS. I am not sure
what that means but I can venture a guess.
But that is not the only issue I see. On the client side there is an
interesting check which is performed FIRST as it parses through the header
elements:
if (headerBlock.isProcessed() || !headerBlock.getMustUnderstand()) {
continue;
}
in the checkMustUnderstand() method of the Axis2Engine. If the response has NO
mustUnderstand attribute at all, no further checking is done. As I understand
it that is wrong. Since the client SET the mustUnderstand attribute to 'true',
the response has to indicate that it was 'understood'. It does that by adding
the mustUnderstand attribute and setting to true.
So I can avoid the must understand attribute error on the client side by doing
one of two things:
1. Do not include the security header in the response (which is a server error
since the 'timestamp' security check is sent in the service request)
2. Do not include the mustUnderstand attribute in the response (which is a
server error since the mustUnderstand attribute is set in the service request)
was (Author: gyannea):
I have done some further work on this problem but I do not know if it is
correct. In the In-handler (in the addressing module) I check for the
mustUnderstand attribute and if it is found and true (or 1) I set the property
to indicate that it has the mustUnderstand. In the creation of the outbound
message in the MessageContextBuilder I add this line of code
newmsgCtx.setProperty(AddressingConstants.ADD_MUST_UNDERSTAND_TO_ADDRESSING_HEADERS,
inMessageContext.getProperty(
AddressingConstants.ADD_MUST_UNDERSTAND_TO_ADDRESSING_HEADERS));
These two changes create the missing attribute in the addressing headers. (I am
not saying this is correct for the Axis2 model because I do not understand its
scope very well at this time; however I want to see if that would solve the
client side error.) However, in spite of the presence of the attributes, the
error STILL comes up. The reason turns out NOT to be on the addressing headers
but in the security header. Though the security header HAS the mustUnderstand
attribute, it apparently has NOT been 'registered' with JAXWS. I am not sure
what that means but I can venture a guess.
But that is not the only issue I see. On the client side there is an
interesting check which is performed FIRST as it parses through the header
elements:
if (headerBlock.isProcessed() || !headerBlock.getMustUnderstand()) {
continue;
}
in the checkMustUnderstand() method of the Axis2Engine. If the response has NO
mustUnderstand attribute at all, no further checking is done. As I understand
it that is wrong. Since the client SET the mustUnderstand attribute to 'true',
the response has to indicate that it was 'understood'. It does that by adding
the mustUnderstand attribute and setting to true.
So I can avoid the must understand attribute error on the client side by doing
one of two things:
1. Do not include the security header in the response (which is a server error
since the 'timestamp' security check is sent in the service request)
2. Do not include the mustUnderstand attribute in the response (which is a
server error since the mustUnderstand attribute is set in the service request)
> No Header in response
> ---------------------
>
> Key: AXIS2-5431
> URL: https://issues.apache.org/jira/browse/AXIS2-5431
> Project: Axis2
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.6.2
> Reporter: Martin Gainty
>
--
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]
