[
https://issues.apache.org/jira/browse/CXF-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timo Heck updated CXF-3105:
---------------------------
Attachment: ParameterProcessor.java.patch
Hi, I found a solution to some part of the problem. You'll find a patch to
ParameterProcessor attached. It's the first time I did this so I hope you can
use the file. If you need anything else let me know.
But this seems to solve only half of the problem described above.
If I understand this correctly the wsdl definition should be customized as well
so that ServiceInfo passes validation. I haven't located the problem exactly
yet but I think there are two things to be fixed. One near
org.apache.cxf.tools.wsdlto.frontend.jaxws.customization.CustomizationParser
and the other one near
org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.
Timo
> jaxws customization parameter renaming not working
> --------------------------------------------------
>
> Key: CXF-3105
> URL: https://issues.apache.org/jira/browse/CXF-3105
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.2.11
> Reporter: Timo Heck
> Attachments: flowcenter.wsdl, ParameterProcessor.java.patch,
> ws-binding.xml
>
>
> Hi,
> I am working on this for a couple of days now with actually finding a
> solution. I am building a ws client from wsdl with CXF wsdl2Java version
> 2.2.11.
> The problem is an element naming issue in the wsdl. As far as I do understand
> I have three choices:
> 1. disable wrapper style
> 2. use autoNameResolution feature
> 3. write my own customization and rename the parameters
> I verified options 1 and 2. Both solves the problem. But I'd like to have
> more control over the generated interface so I'd like to explicitly set the
> parameter names.
> This is how it looks like:
> Wsdl describes a webservice with a method called login().
> This is how request and response definitions look like.
> <xsd:element name="login">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="login" type="fc:flowloginrequest"/>
> <xsd:element name="switchusergroup" type="xsd:int" maxOccurs="1"
> minOccurs="0"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
> <xsd:element name="loginResponse">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="login" type="fc:flowloginresponse"/>
> <xsd:element name="password_temp" type="xsd:string"/>
> <xsd:element name="usergrouplist" type="fc:flowidnamepairs"/>
> <xsd:element name="permissions" type="xsd:string"/>
> <xsd:element name="usertype" type="xsd:string"/>
> <xsd:element name="usertypeid" type="xsd:string"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
> Request and response both hold a local element called login. This is causing
> the trouble I have and if I try to generate code with wrapper style enabled
> this is what I get:
> WSDLToJava Error: Element login has the same name with different types
> If I rename the two local elements to loginRequest (fc:flowloginrequest) and
> loginResponse (fc:flowloginresponse) everything runs just fine. Since I can't
> actually adjust the schema (it's not mine) I have to write my own
> customization file.
> To solve the problem I wanted to rename the method parameter for both
> elements. This is what found by examining JAX-WS spec.
> <?xml version="1.0" encoding="UTF-8"?>
> <jaxws:bindings wsdlLocation="flowcenter.wsdl"
> xmlns:jaxws="http://java.sun.com/xml/ns/jaxws";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns:jaxb="http://java.sun.com/xml/ns/jaxb";
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";
> xmlns:fc="http://www.flowworks.de/flowworks/";
> xsi:schemaLocation="http://java.sun.com/xml/ns/jaxb
> http://java.sun.com/xml/ns/jaxb/bindingschema_2_0.xsd
> http://java.sun.com/xml/ns/jaxws
> http://java.sun.com/xml/ns/jaxws/wsdl_customizationschema_2_0.xsd";>
>
> <!-- rename method parameters-->
> <jaxws:bindings
> node="wsdl:definitions/wsdl:portty...@name='flowcenter']/wsdl:operati...@name='login']">
> <jaxws:parameter
> part="wsdl:definitions/wsdl:messa...@name='loginRequest']/wsdl:pa...@name='parameters']"
> childElementName="login" name="loginRequest"/>
> <jaxws:parameter
> part="wsdl:definitions/wsdl:messa...@name='loginResponse']/wsdl:pa...@name='parameters']"
> childElementName="login" name="loginResponse"/>
> </jaxws:bindings>
> </jaxws:bindings>
> I thought this would do the trick but it doesn't. Even more confusing is that
> if I run the tool with -autoNameResolution and check the code the service
> interface does show part of my declared names above. It looks like this.
> login( Flowloginrequest loginResponse,
> Integer switchusergroup,
> Holder<Flowloginresponse> login,
> Holder<java.lang.String> passwordTemp,
> Holder<Flowidnamepairs> usergrouplist,
> Holder<java.lang.String> permissions,
> Holder<java.lang.String> usertype,
> Holder<java.lang.String> usertypeid
> )
> Note the login parameter from request is renamed to loginResponse and
> response parameter name is ignored. To make this a little more interesting I
> changed the binding declaration to this:
> <!-- rename method parameters-->
> <jaxws:bindings
> node="wsdl:definitions/wsdl:portty...@name='flowcenter']/wsdl:operati...@name='login']">
> <jaxws:parameter
> part="wsdl:definitions/wsdl:messa...@name='loginRequest']/wsdl:pa...@name='parameters']"
> childElementName="login" name="loginRequest"/>
> </jaxws:bindings>
> <jaxws:bindings
> node="wsdl:definitions/wsdl:portty...@name='flowcenter']/wsdl:operati...@name='login']">
> <jaxws:parameter
> part="wsdl:definitions/wsdl:messa...@name='loginResponse']/wsdl:pa...@name='parameters']"
> childElementName="login" name="loginResponse"/>
> </jaxws:bindings>
> This is what the method signature looks like:
> login( Flowloginrequest loginRequest,
> Integer switchusergroup,
> Holder<Flowloginresponse> login,
> Holder<java.lang.String> passwordTemp,
> Holder<Flowidnamepairs> usergrouplist,
> Holder<java.lang.String> permissions,
> Holder<java.lang.String> usertype,
> Holder<java.lang.String> usertypeid
> )
> So I think I am not completely wrong trying to solve this issue by applying a
> customization file but something is not working right.
> I'll try to provide a test case and patch here too.
> Timo
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
