You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Martin Gainty (JIRA)" <ji...@apache.org> on 2012/10/02 14:43:24 UTC
[jira] [Created] (AXIS2-5431) No Header in response
Martin Gainty created AXIS2-5431:
------------------------------------
Summary: 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] [Comment Edited] (AXIS2-5431) No Header in response
Posted by "Brian Reinhold (JIRA)" <ji...@apache.org>.
[ 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] [Commented] (AXIS2-5431) No Header in response
Posted by "Brian Reinhold (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13468482#comment-13468482 ]
Brian Reinhold commented on AXIS2-5431:
---------------------------------------
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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org
[jira] [Commented] (AXIS2-5431) No Header in response
Posted by "Martin Gainty (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13467675#comment-13467675 ]
Martin Gainty commented on AXIS2-5431:
--------------------------------------
if the SOAPHeaders were never populated in Service Client in the first place (then the headers ArrayList wont contain MUST_UNDERSTAND or any other attribute)
here in ServiceClient
public void sendRobust(QName operation, OMElement elem) throws AxisFault {
MessageContext mc = new MessageContext();
fillSOAPEnvelope(mc, elem);
//at this point headers should be filled with SOAPHeaderBlock
OperationClient mepClient = createClient(operation);
mepClient.addMessageContext(mc);
mepClient.execute(true);
}
//which calls fillSOAPEnveloper with the aforementioned MessageContext and the xmlPayload
private void fillSOAPEnvelope(MessageContext messageContext, OMElement xmlPayload)
throws AxisFault {
messageContext.setServiceContext(serviceContext);
SOAPFactory soapFactory = getSOAPFactory();
SOAPEnvelope envelope = soapFactory.getDefaultEnvelope();
if (xmlPayload != null) {
envelope.getBody().addChild(xmlPayload);
}
addHeadersToEnvelope(envelope);
messageContext.setEnvelope(envelope);
}
//which calls addHeadersToEnvelope with the envelope (previously constructed from SOAPFactory)
public void addHeadersToEnvelope(SOAPEnvelope envelope) {
if (headers != null) {
SOAPHeader soapHeader = envelope.getHeader();
for (Object header : headers) {
soapHeader.addChild((OMElement)header);
}
}
}
/ /where do the headers come from..they are added with addHeader(OMElement) or addHeader(SOAPHeaderBlock) ..note the difference!
/**
* Add an arbitrary XML element as a header to be sent with outgoing messages.
* @param header header to be sent (non-<code>null</code>)
*/
public void addHeader(OMElement header) {
/ /at this point the attributes of MUST_UNDERSTAND_PROPERTY are lost
if (headers == null) {
headers = new ArrayList<OMElement>();
}
headers.add(header);
}
/**
* Add SOAP Header to be sent with outgoing messages.
* @param header header to be sent (non-<code>null</code>)
*/
public void addHeader(SOAPHeaderBlock header) {
if (headers == null) {
headers = new ArrayList<OMElement>();
/ /wrong...we cannot use an ArrayList<OMElement> to contain ArrayList<SOAPHeaderBlock>
}
/ / MUST_UNDERSTAND_PROPERTY is lost ..there is no way to retrieve from headers array
headers.add(header);
}
noting the difference of OMElement and SOAPHeaderBlock
public interface SOAPHeaderBlock extends OMSourcedElement {
/**
* A SOAPHeaderBlock may be represented as an unexpanded OMSourcedElement.
* In such cases, the underlying OMDataSource may have a property that contains
* the value of the ROLE/ACTOR, RELAY or MUST_UNDERSTAND setting.
*/
public String ROLE_PROPERTY = "org.apache.axiom.soap.SOAPHeader.ROLE";
public String RELAY_PROPERTY = "org.apache.axiom.soap.SOAPHeader.RELAY";
public String MUST_UNDERSTAND_PROPERTY = "org.apache.axiom.soap.SOAPHeader.MUST_UNDERSTAND";
...
}
so the downcast of SOAPHeaderBlock to OMElement to fit into ArrayList<OMElement> loses MUST_UNDERSTAND_PROPERTY
the ArrayList<OMElement> needs to be ArrayList<SOAPHeaderBlock>
this is not good and needs to be rectified ASAP
> 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org