XFire
  1. XFire
  2. XFIRE-487

WSDL returned by Service created with WsGen does not preserve element types specified in the original WSDL

    Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Windows XP Professional SP2
      Sun Java JDK 1.5.0_07
      Tomcat 5.5.17
    • Number of attachments :
      0

      Description

      I generated a service from an existing WSDL using the WsGen Ant task.
      I then looked at the generated WSDL returned by http://localhost/MyService?wsdl.

      Elements type definitions were not preserved
      1. xsd:date elements were redefined as xsd:datetime. This completely changes the format of the returned information.
      2. xsd:nonNegativeInteger elements were redefined as xsd:int in one case, and as xsd:integer in another case. This negates the possiblilty of range and value checking.
      3. restricted simple types were redefined as their base type (see the "language" and "siteNum" elements). This negates teh possiblity of value checking.

      See the original and generated WSDL attachments in JIRA XFIRE-485

        Activity

        Hide
        Dan Diephouse added a comment -

        This is the same issue as XFIRE-485 - it is either a configuration issue or a bug in jaxbservicefactory. Marking as duplicate.

        Show
        Dan Diephouse added a comment - This is the same issue as XFIRE-485 - it is either a configuration issue or a bug in jaxbservicefactory. Marking as duplicate.
        Hide
        Mike McAngus added a comment -

        Per the recommendation in JIRA XFIRE-485, I modified the serviceFactory of my service.xml file. The WSDL returned when I issued the ?wsdl request still has the problems identified in this ticket.

        1. xsd:date elements were redefined as xsd:datetime. This completely changes the format of the returned information.

        In fact, no the elements that I identified as "xsd:date" are identified in the generated WSDL as "xsd:anySimpleType". The data returned by the service for those elements has still has a datetime format.

        2. xsd:nonNegativeInteger elements were redefined as xsd:int in one case, and as xsd:integer in another case. This negates the possiblilty of range and value checking.

        This issue still exists when using the new serviceFactory.

        3. restricted simple types were redefined as their base type (see the "language" and "siteNum" elements). This negates teh possiblity of value checking.

        This issue still exists when using the new serviceFactory.

        Show
        Mike McAngus added a comment - Per the recommendation in JIRA XFIRE-485 , I modified the serviceFactory of my service.xml file. The WSDL returned when I issued the ?wsdl request still has the problems identified in this ticket. 1. xsd:date elements were redefined as xsd:datetime. This completely changes the format of the returned information. In fact, no the elements that I identified as "xsd:date" are identified in the generated WSDL as "xsd:anySimpleType". The data returned by the service for those elements has still has a datetime format. 2. xsd:nonNegativeInteger elements were redefined as xsd:int in one case, and as xsd:integer in another case. This negates the possiblilty of range and value checking. This issue still exists when using the new serviceFactory. 3. restricted simple types were redefined as their base type (see the "language" and "siteNum" elements). This negates teh possiblity of value checking. This issue still exists when using the new serviceFactory.
        Hide
        Mike McAngus added a comment -

        I figured out that the reason the date fields in the response message had a full dateTime format (yyyy-mm-dd T hh:mm:ss.sssss-zz:zz) is because I fully populated the XMLGregorianCalendar object, including the timezone offset, from my Calendar object.

        When I only set the year, month and day fields in the XMLGregorianCalendar, then the response had only a date field. However, I should not have to limit the populating of the XMLGregorianCalendar in order to have the response data match the definition of the date field being returned.

        My Web Service Implementation class should not be required to have knowledge of the definition of elements in the response message in order to populate the outgoing message correctly. It should be possible to simply move the data from the Business Layer Java Beans to the objects that encapsulate the response data and to have the response SOAP message be properly populated according to the Schema defined by the WSDL.

        Show
        Mike McAngus added a comment - I figured out that the reason the date fields in the response message had a full dateTime format (yyyy-mm-dd T hh:mm:ss.sssss-zz:zz) is because I fully populated the XMLGregorianCalendar object, including the timezone offset, from my Calendar object. When I only set the year, month and day fields in the XMLGregorianCalendar, then the response had only a date field. However, I should not have to limit the populating of the XMLGregorianCalendar in order to have the response data match the definition of the date field being returned. My Web Service Implementation class should not be required to have knowledge of the definition of elements in the response message in order to populate the outgoing message correctly. It should be possible to simply move the data from the Business Layer Java Beans to the objects that encapsulate the response data and to have the response SOAP message be properly populated according to the Schema defined by the WSDL.

          People

          • Assignee:
            Dan Diephouse
            Reporter:
            Mike McAngus
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: