AW: SOAPAction value in AXIS generated stubs causing problems with server upgraded to CXF 1.5.5 from CXF 1.5.0

would be nice to know the difference looking with a TCP Monitor!

Josef



-----Ursprüngliche Nachricht-----
Von: Deepal Jayasinghe [mailto:[email protected]] 
Gesendet: Mittwoch, 30. Januar 2013 17:12
An: [email protected]
Betreff: Re: SOAPAction value in AXIS generated stubs causing problems with server upgraded to CXF 1.5.5 from CXF 1.5.0

I guess this a a bug in the code generator, could you please create a JIRA and attach your WSDL ?

Deepal
> Any suggestions? We are still unable to get the AXIS clients to 
> connect after the CXF 1.5.5 upgrade on the server.
>
> No problems with SoapUI, .Net or CXF clients. If this needs to be 
> reported more officially, where can I do that?
>
> Many thanks.
>
> Wayne
>
> On 1/14/13 6:54 AM, "Wayne Holmes" <[email protected]> wrote:
>
>>
>> On 1/11/13 9:50 PM, "Sagara Gunathunga" <[email protected]>
>> wrote:
>>
>>> On Fri, Jan 11, 2013 at 1:05 AM, Wayne Holmes <[email protected]>
>>> wrote:
>>>> We are doing some interoperability testing, and after upgrading our 
>>>> server to CXF 1.5.5 we are seeing an exception thrown when we send 
>>>> a request from a AXIS 2 client with text:
>>>>    "The given SOAPAction
>>>> http://text2idml.idml.server.cequint.com/Text2IDMLWebServiceImpl/qu
>>>> eryHa
>>>> n
>>>> dsets does not match an operation."
>>>>
>>>> Did a line level trace, and the indeed see that SOAPAction is being 
>>>> set to 
>>>> "http://text2idml.idml.server.cequint.com/Text2IDMLWebServiceImpl/q
>>>> ueryH
>>>> a
>>>> ndsets", even thought the WSDL for that operation specified no action:
>>>>                 <wsdl:operation name="queryHandsets">
>>>>                         <soap:operation soapAction="" style="document"
>>>> />
>>>>                         <wsdl:input name="queryHandsets">
>>>>                                 <soap:body use="literal" />
>>>>                         </wsdl:input>
>>>>                         <wsdl:output name="queryHandsetsResponse">
>>>>                                 <soap:body use="literal" />
>>>>                         </wsdl:output>
>>>>                 </wsdl:operation>
>>>>
>>>> Based on the comments in the security fix in CXF 1.5.5, it sounds 
>>>> to us like CXF is expecting the SOAPAction to be "" since that is 
>>>> what is in the CXF generated WSDL. (See 
>>>> http://cxf.apache.org/cve-2012-3451.html)
>>>>
>>>> I looked at the client generated by WSDL2JAVA (Axis2 version 1.6.2) 
>>>> and found this line:
>>>>                
>>>> _operationClient.getOptions().setAction("http://text2idml.idml.serv
>>>> er.ce
>>>> q
>>>> uint.com/Text2IDMLWebServiceImpl/queryHandsets");
>>>>
>>>> Tried using the same server WSDL to client .Net and SOAPUI clients, 
>>>> and both of them are setting SOAPAction to "", so we are thinking 
>>>> there is an issue with AXIS2 talking to CXF 1.5.5 when the 
>>>> operation soapAction="" in the WSDL.
>>>>
>>>> So my questions are:
>>>> - Is there a way to override the SOAPAction when the stubs are 
>>>> generated?
>>> Try stub._getServiceClient().getOptions().setAction(...)
>>>
>>>
>>> http://axis.apache.org/axis2/java/core/api/org/apache/axis2/client/O
>>> ption
>>> s
>>> .html#setAction%28java.lang.String%29
>>>
>>> Thanks !
>> We tried that, and what happens is the generated stub files end up 
>> overriding the SOAPAction when
>>   
>> _operationClient.getOptions().setAction("http://text2idml.idml.server
>> .cequ
>> i
>> nt.com/Text2IDMLWebServiceImpl/queryHandsets") is called in the 
>> generated stubs.
>>
>> We then altered the generated stub to:
>>   _operationClient.getOptions().setAction("");
>> And the SOAPAction is then changed to "urn:queryHandsets" by what 
>> appears to be some WSA code. (Based on a DEBUG level trace.)
>>
>> Generated clients using SoapUP, CXF and .Net to see what they do. In 
>> all cases the SOAPAction is set to "", which matches the WSDL. For 
>> some reason the AXIS code is insisting on changing the SOAPAction 
>> from what is in the WSDL. (That is, it is treating a SOAPAction of 
>> length zero as a missing
>> value.)
>>
>>>> - If not, any samples for how to override the SOAPAction at runtime 
>>>> when using WSDL2JAVA generated stubs?
>>>>
>>>> Thanks in advance.
>>>>
>>>> Wayne Holmes
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -- To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>>
>>> --
>>> Sagara Gunathunga
>>>
>>> Blog      - http://ssagara.blogspot.com
>>> Web      - http://people.apache.org/~sagara/
>>> LinkedIn - http://www.linkedin.com/in/ssagara
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

--
Blog - http://blogs.deepal.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]