[
https://issues.apache.org/jira/browse/AXIS2-5039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035954#comment-13035954
]
Ivan commented on AXIS2-5039:
-----------------------------
Just update a new patch and a case to reproduce this issue.
Initially, the problem is found while working with RI SAAJ, as it will add a
empty SOAPAction in the MIME header once the writeTo is invoked on SOAPMessage.
But after investigating this later, this real problem is that SOAPAction header
could be set in more than one places, and this could reproduced with Axis2 SAAI
impl.
>From the JAX-WS perspective, SOAPAction attribute is usually set in the
>following popular places :
a. Create SOAPMessage with SAAJ API, then use
message.getMimeHeaders().addHeader method.
b. ((BindingProvider)
dispatch).getRequestContext().put(BindingProvider.SOAPACTION_URI_PROPERTY,
"echoString");
The question is that, if users configures in both places, what will happen ?
The current Axis2 behavior is, #b will be ignored once #a is configured, due
to the logic in the OperationClient,
The attached patch will replace the value from #a if #b is explicitly
configured, and it looks to me more reasonable.
Actually, I could see another problem, e.g. If users configured SOAPAction in
the SOAPMessage, but later it configures ((BindingProvider)
dispatch).getRequestContext().put(BindingProvider.SOAPACTION_USE_PROPERTY,
false); Seems that the action will still be added while copying those headers
in AbstractHttpSender.addCustomHeaders methods. If it makes sense, I will try
to create another patch for it.
Thanks.
> Override the SOAPAction from the SOAPMessage MIME header if it is explicitly
> configured later
> ---------------------------------------------------------------------------------------------
>
> Key: AXIS2-5039
> URL: https://issues.apache.org/jira/browse/AXIS2-5039
> Project: Axis2
> Issue Type: Bug
> Components: jaxws
> Reporter: Ivan
> Attachments: AXIS2-5039-Test.patch, AXIS2-5039.patch
>
>
> While using RI SAAJ impl with Axis2, it seems that RI SAAJ will always adds
> a SOAPAction header with the value "" if it is a SOAP 1.1 message. I found
> that if the action is configured in the requestContext by the
> BindingProvider.SOAPACTION_USE_PROPERTY and
> BindingProvider.SOAPACTION_URI_PROPERTY will be ignored. And it looks to me
> that it makes sense to override the soap action if it is explicitly
> configured with the later way.
> I did a text search for the setSOAPAction method for the MessageContext,
> and its initial values are from SOAPMessage.
> a. o.a.axis2.saaj.SOAPConnectionImpl Line 185
> b. o.a.axis2.jaxws.message.util.MessageUtils Line 206
> Also, for the SOAPAction in the OperationClient, it is configured in
> o.a.axis2.jaxws.core.control.impl.AxisInvocationController.initOperationClient
> method
> --->
> String soapAction = ClientUtils.findSOAPAction(requestMsgCtx);
> <---
> The codes in the ClientUtils.findSOAPAction will check the configurations
> in the RequestContext, and even the action configured in the Operation, it
> looks to me that the SOAPAction here is more valuable.
> The proposed the changes are in the OperationClient.prepareMessageContext
> From
> --->
> if (mc.getSoapAction() == null || "".equals(mc.getSoapAction())) {
> mc.setSoapAction(options.getAction());
> }
> <---
> To
> if (options.getAction() != null || options.getAction().length() > 0) {
> mc.setSoapAction(options.getAction());
> }
> <---
--
This message is automatically generated by JIRA.
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]
