You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "John Williams (JIRA)" <ji...@apache.org> on 2007/08/17 23:46:31 UTC

[jira] Created: (CXF-919) cxf-codgen-plugin needs to depend on cxf-rt-bindings-soap

cxf-codgen-plugin needs to depend on cxf-rt-bindings-soap
---------------------------------------------------------

                 Key: CXF-919
                 URL: https://issues.apache.org/jira/browse/CXF-919
             Project: CXF
          Issue Type: Bug
          Components: Build system
    Affects Versions: 2.0.1, 2.1
         Environment: Maven version: 2.0.7
Java version: 1.5.0_12
OS name: "linux" version: "2.6.11-1.1369_fc4smp" arch: "i386"

            Reporter: John Williams


The wsdl2java goal of the cxf-codegen-plugin silently generates incorrect code because it is not declared to depend on cxf-rt-bindings-soap.  The problem seems to occur when using a SOAP binding with RPC-style encoding for a message part associated with a schema element (i.e. <wsdl:part name="..." element="...").  The symptom is that an incorrect @WebParam annotation is generated, ultimately causing a CXF-based client to marshall its arguments incorrectly.

I considered the possibility that the behavior *without* the dependency on cxf-rt-bindings-soap is more correct, but my reading of section 3.5 of the WSDL 1.1 spec suggests that this is not the case.

Needless to say, adding the missing dependency fixed the problem, but it took me many hours to discover this solution.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-919) cxf-codgen-plugin needs to depend on cxf-rt-bindings-soap

Posted by "John Williams (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521098 ] 

John Williams commented on CXF-919:
-----------------------------------

The issue I found is different from what is addressed in the documentation because cxf-rt-bindings-soap needs to be declared as a dependency of the plugin itself, not of the project, so the POM needs to contain a section like this:

        <plugin>
          <groupId>org.apache.cxf</groupId>
          <artifactId>cxf-codegen-plugin</artifactId>
          <version>${cxf-version}</version>
          <dependencies>
            <dependency>
              <groupId>org.apache.cxf</groupId>
              <artifactId>cxf-rt-bindings-soap</artifactId>
              <version>${cxf-version}</version>
            </dependency>
          </dependencies>
        </plugin>

> cxf-codgen-plugin needs to depend on cxf-rt-bindings-soap
> ---------------------------------------------------------
>
>                 Key: CXF-919
>                 URL: https://issues.apache.org/jira/browse/CXF-919
>             Project: CXF
>          Issue Type: Bug
>          Components: Build system
>    Affects Versions: 2.0.1, 2.1
>         Environment: Maven version: 2.0.7
> Java version: 1.5.0_12
> OS name: "linux" version: "2.6.11-1.1369_fc4smp" arch: "i386"
>            Reporter: John Williams
>
> The wsdl2java goal of the cxf-codegen-plugin silently generates incorrect code because it is not declared to depend on cxf-rt-bindings-soap.  The problem seems to occur when using a SOAP binding with RPC-style encoding for a message part associated with a schema element (i.e. <wsdl:part name="..." element="...").  The symptom is that an incorrect @WebParam annotation is generated, ultimately causing a CXF-based client to marshall its arguments incorrectly.
> I considered the possibility that the behavior *without* the dependency on cxf-rt-bindings-soap is more correct, but my reading of section 3.5 of the WSDL 1.1 spec suggests that this is not the case.
> Needless to say, adding the missing dependency fixed the problem, but it took me many hours to discover this solution.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (CXF-919) cxf-codgen-plugin needs to depend on cxf-rt-bindings-soap

Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CXF-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-919.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 2.0.3


The wsdl2java mojo now uses the project dependencies as well.   If the project depends on soap, it will be available.

> cxf-codgen-plugin needs to depend on cxf-rt-bindings-soap
> ---------------------------------------------------------
>
>                 Key: CXF-919
>                 URL: https://issues.apache.org/jira/browse/CXF-919
>             Project: CXF
>          Issue Type: Bug
>          Components: Build system
>    Affects Versions: 2.0.1, 2.1
>         Environment: Maven version: 2.0.7
> Java version: 1.5.0_12
> OS name: "linux" version: "2.6.11-1.1369_fc4smp" arch: "i386"
>            Reporter: John Williams
>             Fix For: 2.0.3
>
>
> The wsdl2java goal of the cxf-codegen-plugin silently generates incorrect code because it is not declared to depend on cxf-rt-bindings-soap.  The problem seems to occur when using a SOAP binding with RPC-style encoding for a message part associated with a schema element (i.e. <wsdl:part name="..." element="...").  The symptom is that an incorrect @WebParam annotation is generated, ultimately causing a CXF-based client to marshall its arguments incorrectly.
> I considered the possibility that the behavior *without* the dependency on cxf-rt-bindings-soap is more correct, but my reading of section 3.5 of the WSDL 1.1 spec suggests that this is not the case.
> Needless to say, adding the missing dependency fixed the problem, but it took me many hours to discover this solution.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (CXF-919) cxf-codgen-plugin needs to depend on cxf-rt-bindings-soap

Posted by "maomaode (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521008 ] 

maomaode commented on CXF-919:
------------------------------

Here is the doc http://cwiki.apache.org/confluence/display/CXF20DOC/Maven+Integration+and+Plugin,
It said to include the jaxws frontend, which turns include the soap binding

At moment we just can not put the jaxws/soap dependencies into our code-gen plugin, there's cyclic dependencies in the testutils module, but hope we can solve it soon.

> cxf-codgen-plugin needs to depend on cxf-rt-bindings-soap
> ---------------------------------------------------------
>
>                 Key: CXF-919
>                 URL: https://issues.apache.org/jira/browse/CXF-919
>             Project: CXF
>          Issue Type: Bug
>          Components: Build system
>    Affects Versions: 2.0.1, 2.1
>         Environment: Maven version: 2.0.7
> Java version: 1.5.0_12
> OS name: "linux" version: "2.6.11-1.1369_fc4smp" arch: "i386"
>            Reporter: John Williams
>
> The wsdl2java goal of the cxf-codegen-plugin silently generates incorrect code because it is not declared to depend on cxf-rt-bindings-soap.  The problem seems to occur when using a SOAP binding with RPC-style encoding for a message part associated with a schema element (i.e. <wsdl:part name="..." element="...").  The symptom is that an incorrect @WebParam annotation is generated, ultimately causing a CXF-based client to marshall its arguments incorrectly.
> I considered the possibility that the behavior *without* the dependency on cxf-rt-bindings-soap is more correct, but my reading of section 3.5 of the WSDL 1.1 spec suggests that this is not the case.
> Needless to say, adding the missing dependency fixed the problem, but it took me many hours to discover this solution.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.