Axis
  1. Axis
  2. AXIS-1366

Service re-creates incorrect WSDL

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: WSDL processing
    • Labels:
      None
    • Environment:
      Windows 2003 Server.
      JDK 1.4.2_03

      Description

      I create a Web Service from WSDL in which the Schema has elementFormDefault="unqualified" (in fact I just use the default)

      I deploy the service without any WSDL.

      I browse to the service using ?WSDL and I see that the schema in the WSDL uses elementFormDefault="qualified"

      The bizarre thing is that if I generate a client from the WSDL the client sends the wrong request (everything is qualified) but the server still works, and the server sends the wrong reeponse (so far as the client is concerned as it uses unqualified elements) and the client accepts it.

      It seems like the problem is that the server, when it generates the WSDL, doesn't know to use unqualified. Maybe another WSDD parameter is needed?

      1. CommunityInformation.wsdl
        7 kB
        Alan Green
      2. AxisTest.wsdl
        2 kB
        Dan Ciarniello

        Activity

        Hide
        Davanum Srinivas added a comment -

        Fixed in latest CVS.

        thanks,
        dims

        Show
        Davanum Srinivas added a comment - Fixed in latest CVS. thanks, dims
        Hide
        Davanum Srinivas added a comment -

        Upgrading to blocker

        – dims

        Show
        Davanum Srinivas added a comment - Upgrading to blocker – dims
        Hide
        Alan Green added a comment -

        I'm seeing the opposite problem with 1.2RC2: the hand-coded WSDL uses elementFormDefault="qualified", but the generated WSDL omits the elementFormDefault attribute.

        This is a painful bug for us. I have attached "CommunityInformation.wsdl"

        Show
        Alan Green added a comment - I'm seeing the opposite problem with 1.2RC2: the hand-coded WSDL uses elementFormDefault="qualified", but the generated WSDL omits the elementFormDefault attribute. This is a painful bug for us. I have attached "CommunityInformation.wsdl"
        Hide
        Davanum Srinivas added a comment -

        Glen,

        Can you please take a look at this one? We are always hard coding elementFormDefault to "qualified" for Style.DOCUMENT/WRAPPED in org.apache.axis.wsdl.fromJava.Types class (line 914)

        thanks,
        dims

        Show
        Davanum Srinivas added a comment - Glen, Can you please take a look at this one? We are always hard coding elementFormDefault to "qualified" for Style.DOCUMENT/WRAPPED in org.apache.axis.wsdl.fromJava.Types class (line 914) thanks, dims
        Hide
        Dan Ciarniello added a comment -

        I've attached a WSDL file that illustrates how the elementFormDefault issue affects WSDL2Java.

        1. Take the attached WSDL (which does not have elementFormDefault defined), generate server side classes and deploy with AdminClient and the generated deploy.wsdd.
        2. Use WSDL2Java to generate client side classes from the generated WSDL.
        3. Attempt to invoke the service. A NullPointerException should be thrown.
        4. Add elementFormDefault="qualified" to the WSDL and repeat steps 1 to 3. This time, everything should work as expected.

        Show
        Dan Ciarniello added a comment - I've attached a WSDL file that illustrates how the elementFormDefault issue affects WSDL2Java. 1. Take the attached WSDL (which does not have elementFormDefault defined), generate server side classes and deploy with AdminClient and the generated deploy.wsdd. 2. Use WSDL2Java to generate client side classes from the generated WSDL. 3. Attempt to invoke the service. A NullPointerException should be thrown. 4. Add elementFormDefault="qualified" to the WSDL and repeat steps 1 to 3. This time, everything should work as expected.
        Hide
        Dan Ciarniello added a comment -

        I think that this bug has a lot to do with some of the interoperability issues, expecially with .NET. deploy.wsdd files generated with WSDL2Java reflect the value of the elementFormDefault value but since the WSDL generator always adds elementFormDefault="qualified", the service will often produce SOAP responses that do not match what the WSDL tells the client to expect.

        For example, when elementFormDefault="unqualified", the service produces unqualified elements (xmlns="") but the WSDL is telling clients to expect qualified elements. .Net, in particular, has problems with this but so do WSDL2Java-generated clients if the WSDL is set up in a particular way (see the attached WSDL).

        Show
        Dan Ciarniello added a comment - I think that this bug has a lot to do with some of the interoperability issues, expecially with .NET. deploy.wsdd files generated with WSDL2Java reflect the value of the elementFormDefault value but since the WSDL generator always adds elementFormDefault="qualified", the service will often produce SOAP responses that do not match what the WSDL tells the client to expect. For example, when elementFormDefault="unqualified", the service produces unqualified elements (xmlns="") but the WSDL is telling clients to expect qualified elements. .Net, in particular, has problems with this but so do WSDL2Java-generated clients if the WSDL is set up in a particular way (see the attached WSDL).

          People

          • Assignee:
            Glen Daniels
            Reporter:
            Kevin Jones
          • Votes:
            3 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development