And, if I remove the other execution from this particular pom.xml it:
a) Generates the correct java for RefDataService.wsdl
AND
b) Generates java for the other wsdl file in the same location as RefDataService.wsdl, despite not having an execution for it.

Now I'm really confused.

Jim

On 03/12/2010 15:49, Jim Talbut wrote:


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



Reply via email to