cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Talbut <jtal...@spudsoft.co.uk>
Subject Unable to get cxf-codegen-plugin to pick up arguments to wsdl2java that work on the command line.
Date Fri, 03 Dec 2010 15:49:30 GMT


Hi,

Using the cxf-codegen-plugin seems to produce different results to 
calling wsdl2java directly (particularly with regard to arguments passed 
in).

Example one:

<execution>

<id>generate-service</id>

<phase>generate-sources</phase>

<configuration>

<wsdlOptions>

<wsdlOption>

<wsdl>src/main/resources/wsdl/RefDataService.wsdl</wsdl>

<bindingFiles>

<bindingFile>${basedir}/src/main/resources/wsdl/RefDataServiceBinding.xml</bindingFile>

</bindingFiles>

<extraargs>

<extraarg>-server</extraarg>

<!-- Note that the next two are a pair, without them the path to the 
WSDL file gets hardcoded in the Service -->

<extraarg>-wsdlLocation</extraarg>

<extraarg></extraarg>

</extraargs>

</wsdlOption>

</wsdlOptions>

</configuration>

<goals>

<goal>wsdl2java</goal>

</goals>

</execution>

The binding file is supposed to generate java.util.Date for 
xsd:dateTime, but the output is still using 
javax.xml.datatype.XMLGregorianCalendar.

But if I run the following from a command line:

wsdl2java -b RefDataServiceBinding.xml RefDataService.wsdl

it works correctly.

Example two:

Trying to pass the --exsh argument makes no difference:

<extraarg>-exsh</extraarg>

<extraarg>true</extraarg>

This was using a .Net WCF WSDL file with a lot of parameters needing to 
be passed in the SOAP:header -- without exsh the generated code is unusable.

For this one I ended up generating the code at the command line.


I've tried a few different versions of CXF, this is currently using  2.3.0.


Running with mvn -X turns up the following line (edited to remove path 
root):
[DEBUG] Calling wsdl2java with args: [-d, 
PATHROOT\target\generated-sources\cxf, -verbose, 
file:/PATHROOT/src/main/resources/wsdl/RefDataService.wsdl]

Even the wsdlLocation argument has been lost - though there is another 
execution in the same pom.xml that also has a wsdlLocation argument that 
IS being passed to wsdl2java.

Does the problem relate to requirin multiple calls to wsdl2java in a 
single pom?


Jim


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message