Axis2
  1. Axis2
  2. AXIS2-5249

Axis2 1.6.1 generates invalid request when using JAXBRI bindings

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 1.6.1
    • Fix Version/s: 1.7.0
    • Component/s: databinding
    • Labels:
      None
    • Environment:
      Windows, Solaris

      Description

      The client generated using JAXBRI bindings creates invalid request XML with version 1.6.1. The same code works with Axis 2 1.5.1 using JAXBRI bindings and Axis 2 1.6.1 using ADB bindings.

      This problem seems to impact several clients for various Web Services. All clients were working fine with Axis 2 1.5.1.

      I will attach WSDL, test client, and code generation commands to this ticket.

      1. ESubServices.wsdl
        21 kB
        Dmitriy
      2. ESubTest.java
        1 kB
        Dmitriy
      3. build.xml
        2 kB
        Dmitriy
      4. ESubServices.wsdl
        19 kB
        Dmitriy

        Issue Links

          Activity

          Dmitriy created issue -
          Hide
          Dmitriy added a comment -

          server WSDL

          Show
          Dmitriy added a comment - server WSDL
          Dmitriy made changes -
          Field Original Value New Value
          Attachment ESubServices.wsdl [ 12515598 ]
          Hide
          Dmitriy added a comment -

          Test client using JAXBRI

          Show
          Dmitriy added a comment - Test client using JAXBRI
          Dmitriy made changes -
          Attachment ESubTest.java [ 12515599 ]
          Hide
          Dmitriy added a comment -

          Segment of the build script used to generate code from WSDL. Changing this from "jaxbri" to "adb" produces worable client.

          Show
          Dmitriy added a comment - Segment of the build script used to generate code from WSDL. Changing this from "jaxbri" to "adb" produces worable client.
          Dmitriy made changes -
          Attachment build.xml [ 12515600 ]
          Hide
          Dmitriy added a comment -

          Alternative version of WSDL corrected manually (original file is auto-generated by Axis 2 server).

          Show
          Dmitriy added a comment - Alternative version of WSDL corrected manually (original file is auto-generated by Axis 2 server).
          Dmitriy made changes -
          Attachment ESubServices.wsdl [ 12515614 ]
          Hide
          Andreas Veithen added a comment -

          Can you be a bit more specific and define "invalid"? Can you show the problem based on a sample request?

          Show
          Andreas Veithen added a comment - Can you be a bit more specific and define "invalid"? Can you show the problem based on a sample request?
          Hide
          Dmitriy added a comment -

          The generated code produces request:

          <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><ns2:getPersonInfo xmlns:ns2="https://esub.era.nih.gov/eraexchange/eSubServices" xmlns="http://types.ws.eraexchange.nih.gov/"><credential><password>NIH_GUIDE</password><dunsId>001910777</dunsId><tradingPartnerId>easy</tradingPartnerId></credential><commonsUserId>AALBERG</commonsUserId></ns2:getPersonInfo></soapenv:Body></soapenv:Envelope>

          while the correct request should be like:

          <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><ns2:getPersonInfoElement xmlns:ns2="http://ws.eraexchange.nih.gov/" xmlns="http://types.ws.eraexchange.nih.gov/"><credential><password>NIH_GUIDE</password><dunsId>001910777</dunsId><tradingPartnerId>easy</tradingPartnerId></credential><commonsUserId>AALBERG</commonsUserId></ns2:getPersonInfoElement></soapenv:Body></soapenv:Envelope>

          The problem can be resolved by changing the generated Stub code from:

          env = toEnvelope(getFactory(_operationClient.getOptions().getSoapVersionURI()), getPersonInfoElement4, optimizeContent(new javax.xml.namespace.QName("https://esub.era.nih.gov/eraexchange/eSubServices", "getPersonInfo")), new javax.xml.namespace.QName("https://esub.era.nih.gov/eraexchange/eSubServices", "getPersonInfo"));

          to:

          env = toEnvelope(getFactory(_operationClient.getOptions().getSoapVersionURI()), getPersonInfoElement4, optimizeContent(new javax.xml.namespace.QName("http://ws.eraexchange.nih.gov/","getPersonInfoElement")), new javax.xml.namespace.QName("http://ws.eraexchange.nih.gov/","getPersonInfoElement"));

          Basically, the genertaed code uses "type" namespace and name instead of "element" namespace and name thus producing incorrect XML for the request. The organization policy prevent us from modifying the generated code, so we are in a bind. Your help will be appreciated.

          Show
          Dmitriy added a comment - The generated code produces request: <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><ns2:getPersonInfo xmlns:ns2="https://esub.era.nih.gov/eraexchange/eSubServices" xmlns="http://types.ws.eraexchange.nih.gov/"><credential><password>NIH_GUIDE</password><dunsId>001910777</dunsId><tradingPartnerId>easy</tradingPartnerId></credential><commonsUserId>AALBERG</commonsUserId></ns2:getPersonInfo></soapenv:Body></soapenv:Envelope> while the correct request should be like: <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><ns2:getPersonInfoElement xmlns:ns2="http://ws.eraexchange.nih.gov/" xmlns="http://types.ws.eraexchange.nih.gov/"><credential><password>NIH_GUIDE</password><dunsId>001910777</dunsId><tradingPartnerId>easy</tradingPartnerId></credential><commonsUserId>AALBERG</commonsUserId></ns2:getPersonInfoElement></soapenv:Body></soapenv:Envelope> The problem can be resolved by changing the generated Stub code from: env = toEnvelope(getFactory(_operationClient.getOptions().getSoapVersionURI()), getPersonInfoElement4, optimizeContent(new javax.xml.namespace.QName("https://esub.era.nih.gov/eraexchange/eSubServices", "getPersonInfo")), new javax.xml.namespace.QName("https://esub.era.nih.gov/eraexchange/eSubServices", "getPersonInfo")); to: env = toEnvelope(getFactory(_operationClient.getOptions().getSoapVersionURI()), getPersonInfoElement4, optimizeContent(new javax.xml.namespace.QName("http://ws.eraexchange.nih.gov/","getPersonInfoElement")), new javax.xml.namespace.QName("http://ws.eraexchange.nih.gov/","getPersonInfoElement")); Basically, the genertaed code uses "type" namespace and name instead of "element" namespace and name thus producing incorrect XML for the request. The organization policy prevent us from modifying the generated code, so we are in a bind. Your help will be appreciated.
          Andreas Veithen made changes -
          Link This issue duplicates AXIS2-5147 [ AXIS2-5147 ]
          Hide
          Andreas Veithen added a comment -

          I believe that this is a duplicate of AXIS2-5147.

          Show
          Andreas Veithen added a comment - I believe that this is a duplicate of AXIS2-5147 .
          Andreas Veithen made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Assignee Andreas Veithen [ veithen ]
          Fix Version/s 1.7.0 [ 12316136 ]
          Resolution Duplicate [ 3 ]
          Hide
          Nicolae Petridean added a comment - - edited

          Hi guys,
          is there a way to avoid this by keeping jaxbri as databinding provider?
          I've tried 1.7.0 snapshot , but it is not a working solution yet.

          Best regards, Nicu

          Show
          Nicolae Petridean added a comment - - edited Hi guys, is there a way to avoid this by keeping jaxbri as databinding provider? I've tried 1.7.0 snapshot , but it is not a working solution yet. Best regards, Nicu

            People

            • Assignee:
              Andreas Veithen
              Reporter:
              Dmitriy
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development