axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AXIS2-5039) Override the SOAPAction from the SOAPMessage MIME header if it is explicitly configured later
Date Thu, 19 May 2011 02:38:47 GMT

    [ 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: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org


Mime
View raw message