XFire

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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Vote (1)
Watch (1)

Dates

  • Created:
    Updated: