Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Not A Problem
-
2.3.3
-
Windows 7 Service Pack 1
Java JDK 1.60_22
Maven 3.01
cxf-codegen-plugin 2.3.3
-
Unknown
Description
I think I found a bug in the code generation used/made by CXF. I discovered it while using the cxf-codegen-plugin for Maven. The bug is related to WSDL elements that use the attribute "nillable" set to "true". I made a little example which I'll attach to this bug report. In the example there is a complexType "Message":
<xsd:complexType name="Message"> <xsd:sequence> <xsd:element minOccurs="0" name="body" nillable="true" type="xsd:string"/> </xsd:sequence> </xsd:complexType>
Using this complexType the resulting xml output looks like this:
<?xml version="1.0" ?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:SendMessage xmlns:ns2="http://www.example.org/codegenbug/"> <message> <ns2:codegenbug>New Message</ns2:codegenbug> </message> </ns2:SendMessage> </S:Body> </S:Envelope>
(FYI: codegenbug is the name of the webservice)
If you change the body element in the complexType "Message" to:
<xsd:element minOccurs="0" name="body" type="xsd:string"/>
you get the correct xml output:
<?xml version="1.0" ?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:SendMessage xmlns:ns2="http://www.example.org/codegenbug/"> <message> <body>New Message</body> </message> </ns2:SendMessage> </S:Body> </S:Envelope>
As you can see in the above example, without nillable=true the xml output (or message) is generated correct. While I tested different constellations of minOccurs, maxOccurs and nillable=true I noticed that all the problems only occured when nillable=true is used. Using nillable=true results in setter methods that require you to wrap your data in a JAXBElement. So my guess is that this problem is caused by the way the codegen works with those JAXBElements.
—
To test this I created a Maven Project with a test wsdl and a junit test. To have a look at the xml output I run the query through tcpmon. You can download tcpmon here:
http://ws.apache.org/commons/tcpmon/download.cgi
In the WSDL I set the endpoint to "http://127.0.0.1:10000". So you need to make tcpmon listen on port "10000". The target endpoint is "127.0.0.1" and port "8088". To quickly create a mockup endpoint I used soapUI. You can download soupUI here:
http://sourceforge.net/projects/soapui/files/soapui/3.6.1/
I attached the soupUI project to the ticket.
After you set up everything you can run "mvn clean test". You should get a build failure. But this is ok. There should be a soap message in tcpmon. In this soap message you can see the faulty xml message.