2.2.[4-7] not WSDL compatible with 2.2.3 - Parameter: attr already exists for
method XXX but of type YYY instead of ZZZ
-----------------------------------------------------------------------------------------------------------------------
Key: CXF-2797
URL: https://issues.apache.org/jira/browse/CXF-2797
Project: CXF
Issue Type: Bug
Affects Versions: 2.2.7
Environment: java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
Reporter: Bruce Edge
I had a wsdl first service that was working fine with 2.2.3. I decided to move
to 2.2.7 in the interest of staying current.
After doing so, I started getting an error in the wsdl code gen phase of maven:
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Parameter: attr already exists for method hasPortAttr but of type
com.lsi.osa.dpm.types.HasPortAttrType instead of boolean. Use a JAXWS/JAXB
binding customization to rename the parameter.
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Parameter: attr already
exists for method hasPortAttr but of type com.lsi.osa.dpm.types.HasPortAttrType
instead of boolean. Use a JAXWS/JAXB binding customization to rename the
parameter.
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException: Parameter: attr
already exists for method hasPortAttr but of type
com.lsi.osa.dpm.types.HasPortAttrType instead of boolean. Use a JAXWS/JAXB
binding customization to rename the parameter.
at
org.apache.cxf.maven_plugin.WSDL2JavaMojo.callWsdl2Java(WSDL2JavaMojo.java:409)
at
org.apache.cxf.maven_plugin.WSDL2JavaMojo.execute(WSDL2JavaMojo.java:361)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.cxf.tools.common.ToolException: Parameter: attr already
exists for method hasPortAttr but of type com.lsi.osa.dpm.types.HasPortAttrType
instead of boolean. Use a JAXWS/JAXB binding customization to rename the
parameter.
at
org.apache.cxf.tools.common.model.JavaMethod.addParameter(JavaMethod.java:180)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.ParameterProcessor.addParameter(ParameterProcessor.java:126)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.ParameterProcessor.processWrappedAbstractOutput(ParameterProcessor.java:429)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.ParameterProcessor.processWrappedOutput(ParameterProcessor.java:360)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.ParameterProcessor.buildParamModelsWithoutOrdering(ParameterProcessor.java:657)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.ParameterProcessor.process(ParameterProcessor.java:86)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.OperationProcessor.processMethod(OperationProcessor.java:136)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.OperationProcessor.process(OperationProcessor.java:62)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.PortTypeProcessor.process(PortTypeProcessor.java:139)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.WSDLToJavaProcessor.wsdlDefinitionToJavaModel(WSDLToJavaProcessor.java:88)
at
org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.WSDLToJavaProcessor.process(WSDLToJavaProcessor.java:60)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:238)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:128)
at
org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:271)
at
org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
at
org.apache.cxf.maven_plugin.WSDL2JavaMojo.callWsdl2Java(WSDL2JavaMojo.java:406)
... 20 more
The wsl code that was causing this is here:
<element name="hasPortAttrResponse">
<complexType>
<sequence>
<element name="attr" type="boolean"/>
</sequence>
</complexType>
</element>
<element name="getPortAttr">
<complexType>
<sequence>
<element name="attr" type="dpmtypes:GetPortAttrType"/>
</sequence>
</complexType>
</element>
Changing it to this fixes the build error, but I'm wondering why elements in a
different scope are conflicting with each other.
<element name="hasPortAttr">
<complexType>
<sequence>
<element name="name" type="dpmtypes:HasPortAttrType"/>
</sequence>
</complexType>
</element>
<element name="hasPortAttrResponse">
<complexType>
<sequence>
<element name="attr" type="boolean"/>
</sequence>
</complexType>
</element>
I just had to make sure that the request and response didn't use the same name
for parameters of different types.
This was not a problem in 2.2.3 so it seems like this is a regression.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
