[ 
https://issues.apache.org/jira/browse/CXF-1478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579048#action_12579048
 ] 

Damien B commented on CXF-1478:
-------------------------------

The thing is, the same code is working in 2.0.2. So I don't know if the problem 
lies with the reading WebParam or if the information is stored somewhere else. 
But it would seem quite normal than using exclusively CXF (wsdl2java with 
validation, server and client), would lead to a working webservice. Or, at the 
very least, produce a warning when the server frontend is guessing the 
parameters.

> WebParam ignored in service implementation
> ------------------------------------------
>
>                 Key: CXF-1478
>                 URL: https://issues.apache.org/jira/browse/CXF-1478
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.0.4
>            Reporter: Damien B
>
> I have a very simple WSDL (see attached file), Doc/Lit/bare.
> I generate with WSDL2Java server + impl. The generated Jax-WS interface looks 
> like this:
> public interface TestDocLit {
>     @ResponseWrapper(localName = "operation1Response", targetNamespace = 
> "http://www.example.org/TestDocLit/";, className = 
> "org.example.testdoclit.Operation1Response")
>     @RequestWrapper(localName = "operation1", targetNamespace = 
> "http://www.example.org/TestDocLit/";, className = 
> "org.example.testdoclit.Operation1")
>     @WebResult(name = "out", targetNamespace = "")
>     @WebMethod(action = "http://www.example.org/TestDocLit/operation1";)
>     public java.lang.String operation1(
>         @WebParam(name = "par1", targetNamespace = "")
>         int par1
>     );
> }
> We note that WebParam is correct (no namespace, "par1").
> The service is tested like this:
> ServerFactoryBean svrFactory = new ServerFactoryBean();
> svrFactory.setServiceClass(TestDocLit.class);
> svrFactory.setAddress(url);
> svrFactory.setServiceBean(new TestDocLitImpl());
> svrFactory.create();
> final Service service = Service.create(TestDocLit_Service.SERVICE);
> service.addPort(TestDocLit_Service.TestDocLitSOAP, 
> SOAPBinding.SOAP11HTTP_BINDING, url);
> service.getPort(TestDocLit_Service.TestDocLitSOAP, 
> TestDocLit.class).operation1(42);
> The message sent by the client seems correct:
> <soap:Envelope 
> xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><ns2:operation1
>  
> xmlns:ns2="http://www.example.org/TestDocLit/";><par1>42</par1></ns2:operation1></soap:Body></soap:Envelope>
> But debugging through DocLiteralInInterceptor::getPara, it appears that the 
> service expects a ("http://testdoclit.example.org/":"arg0";), whereas it 
> receives a ("":par1), thus, we have in return the dreaded:
> null while invoking public abstract java.lang.String 
> org.example.testdoclit.TestDocLit.operation1(int) with params [null].
> So, the server has basically lost the parameter's name, and added a target 
> namespace which (maybe) not due.
> At http://localhost:9000/TestDocLit?wsdl, the generated WSDL exposes this 
> fact as well:
> <wsdl:message name="operation1">
>     <wsdl:part element="tns:operation1" name="parameters">
>     </wsdl:part>
>   </wsdl:message>
> and tns:operation1 is defined below:
> <xsd:element name="operation1" type="tns:operation1"/>
> <xsd:complexType name="operation1">
> <xsd:sequence>
> <xsd:element name="arg0" type="xsd:int"/>
> </xsd:sequence>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to