axis 1.x is not lenient, but it has a bug/feature, that even if it cannot 
match qname to field it's trying to match field name with local name of 
element. 
This way it's possible to deserialize also invalid request in many cases.

jano




Philipp Leitner <[EMAIL PROTECTED]> 
07/29/2008 12:06
Bitte antworten an
[email protected]


An
[email protected]
Kopie

Thema
Re: Different behaviors between Axis and CXF for namespaces  [Virus 
checked]






Correct me if I'm wrong, but isn't the second variant semantically 
different to the first one? In the first variant, 'dossier' and 
'canal' are in the default namespace, while they are in the 
'http://localhost/pdr/services/' 
  namespace in the second one (again, correct me if I'm wrong, but 
this is what I think how xmlns="..." works).

IIRC the old Axis was rather lenient in terms of Namespaces, unlike 
newer frameworks such as CXF. This may explain why the old Axis 
happily accepted your invocation, while CXF does not.

/philipp

On Jul 29, 2008, at 11:52 AM, ARDOUIN, Stéphane wrote:

> Hi,
>
> I have a difference of behavior about namespaces between Axis 1.1 
> and CXF 2.0.8 that I'd like to understand.
>
> For the WSDL I joined to this email, if I send the following 
> request, the behavior of the webservice implemented with CXF 2.0.8 
> is OK :
> Request generated with soap-UI :
> <soapenv:Envelope xmlns:soapenv="
http://schemas.xmlsoap.org/soap/envelope/ 
> " xmlns:ser="http://localhost/pdr/services/";>
>    <soapenv:Header/>
>    <soapenv:Body>
>       <ser:consulterSoldeRequete>
>          <dossier>0683690006</dossier>
>          <canal>SWI</canal>
>       </ser:consulterSoldeRequete>
>    </soapenv:Body>
> </soapenv:Envelope>
>
> Response (CXF) is OK :
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>    <soap:Body>
>       <ns2:consulterSoldeReponse xmlns:ns2="
http://localhost/pdr/services/ 
> ">
> [...]
>       </ns2:consulterSoldeReponse>
>    </soap:Body>
> </soap:Envelope>
>
> But the following request, which worked for the webservice 
> implemented with Axis 1.1 no longer works for the webservice 
> implemented with CXF 2.0.8 :
>
> Request which was OK with Axis but KO with CXF 2.0.8  :
> <soapenv:Envelope xmlns:soapenv="
http://schemas.xmlsoap.org/soap/envelope/ 
> ">
>    <soapenv:Header/>
>    <soapenv:Body>
>       <consulterSoldeRequete xmlns="http://localhost/pdr/services/";>
>          <dossier>0683690006</dossier>
>          <canal>SWI</canal>
>       </consulterSoldeRequete>
>    </soapenv:Body>
> </soapenv:Envelope>
>
> The response (CXF) is KO : an applicative error is returned because 
> the java objects dynamically provided by CXF contain null 
> attributes. The software checks this attributes, and returns this 
> error, saying that mandatory fields are missing in the request.
>
> The difference lies in the fact that the second request doesn't 
> specify the namespace in the same manner : it uses a default 
> namespace. But with Axis 1.1, it didn't matter.
> This is related to the following section of the WSDL :
> <operation name="consulterSolde">
>              <input>
>                  <soap:body namespace="http://localhost/pdr/ 
> services/" use="literal"/>
>              </input>
>              <output>
>                  <soap:body namespace="http://localhost/pdr/ 
> services/" use="literal"/>
>              </output>
> </operation>
>
> Workaround :
> If I remove the namespace in the soap:body element of the operation 
> in the binding section of the WSDL, and regenerate the webservice, 
> the second request becomes OK.
>
> Could you tell me if this is normal, or if you plan to handle that 
> in a future release ?
>
> Thank you in advance.
>
> Stéphane Ardouin
>
> <service_consulter.zip>




Reply via email to