[ 
https://issues.apache.org/jira/browse/CXF-3449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Lauterbach updated CXF-3449:
---------------------------------

    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":

{code}
<xsd:complexType name="Message">
  <xsd:sequence>
    <xsd:element minOccurs="0" name="body" nillable="true" type="xsd:string"/>
  </xsd:sequence>
</xsd:complexType>
{code}

Using this complexType the resulting xml output looks like this:

{code}
<?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>
{code}

(FYI: _codegenbug_ is the name of the webservice)

If you change the body element in the complexType "Message" to:

{code}<xsd:element minOccurs="0" name="body" type="xsd:string"/>{code}

you get the correct xml output:

{code}
<?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>
{code}

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.

  was:
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":

{code}
<xsd:complexType name="Message">
  <xsd:sequence>
    <xsd:element minOccurs="0" name="body" nillable="true" type="xsd:string"/>
  </xsd:sequence>
</xsd:complexType>
{code}

Using this complexType the resulting xml output looks like this:

{code}
<?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>
{code}

(FYI: _codegenbug_ is the name of the webservice)

If you change the body element in the complexType "Message" to:

{code}<xsd:element minOccurs="0" name="body" type="xsd:string"/>{code}

you get the correct xml output:

{code}
<?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>
{code}

As you can see in the above example, without *nillable=true* the xml output (or 
message) is generated correct.
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.


Added my observations regarding JAXBEelements.

> cxf-codegen-plugin produces wrong code for wsdl elements with nillable="true"
> -----------------------------------------------------------------------------
>
>                 Key: CXF-3449
>                 URL: https://issues.apache.org/jira/browse/CXF-3449
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.3.3
>         Environment: Windows 7 Service Pack 1
> Java JDK 1.60_22
> Maven 3.01
> cxf-codegen-plugin 2.3.3
>            Reporter: Jens Lauterbach
>              Labels: cxf-codegen-plugin, maven
>         Attachments: codegenbug.zip
>
>
> 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":
> {code}
> <xsd:complexType name="Message">
>   <xsd:sequence>
>     <xsd:element minOccurs="0" name="body" nillable="true" type="xsd:string"/>
>   </xsd:sequence>
> </xsd:complexType>
> {code}
> Using this complexType the resulting xml output looks like this:
> {code}
> <?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>
> {code}
> (FYI: _codegenbug_ is the name of the webservice)
> If you change the body element in the complexType "Message" to:
> {code}<xsd:element minOccurs="0" name="body" type="xsd:string"/>{code}
> you get the correct xml output:
> {code}
> <?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>
> {code}
> 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.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to