Axis2
  1. Axis2
  2. AXIS2-4370

Time portion of java.util.Date is missing from SOAP response in Axis2 1.5

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Not a Problem
    • Affects Version/s: 1.5
    • Fix Version/s: None
    • Component/s: adb
    • Labels:
      None

      Description

      When a method returns a java.util.Date (or an object containing a java.util.Date), only the date portion is returned in Axis2 1.5:

      <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
      <soapenv:Body>
      <ns:getCurrentTimeResponse xmlns:ns="http://ws.apache.org/axis2">
      <ns:return>2009-06-10</ns:return>
      </ns:getCurrentTimeResponse>
      </soapenv:Body>
      </soapenv:Envelope>

      In Axis2 1.4.1, the full date and time was returned:

      <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
      <soapenv:Body>
      <ns:getCurrentTimeResponse xmlns:ns="http://ws.apache.org/axis2">
      <ns:return>2009-06-10T16:22:22.622Z</ns:return>
      </ns:getCurrentTimeResponse>
      </soapenv:Body>
      </soapenv:Envelope>

      This change breaks any application that requires the time portion to function correctly.

      1. Server.java
        0.1 kB
        Pétur Runólfsson
      2. services.xml
        0.2 kB
        Pétur Runólfsson
      3. Server-1.4.1.wsdl
        4 kB
        Pétur Runólfsson
      4. Server-1.5.wsdl
        4 kB
        Pétur Runólfsson

        Issue Links

          Activity

          Hide
          Bernhard Schauer added a comment - - edited

          @Sagara
          If you look at the .wsdl files attached to this ticket then you'll see that the behaviour of Axis2 changed from 1.4.1 to 1.5 so, that java.util.date mapped to xsd:DataTime in 1.4.1 and mapps to xsd:Date after 1.5. That's one of the initial points of this Ticket. As there is a data loss starting with Axis2 1.5 this is clearly a bug and not "Not A Problem" in my opinion.
          One thing ignored here is the fact, that the behaviour changed between 1.4 and 1.5, so one can't update Axis2 to 1.5 if you rely on having java.util.Date objects being transferred correctly.

          Show
          Bernhard Schauer added a comment - - edited @Sagara If you look at the .wsdl files attached to this ticket then you'll see that the behaviour of Axis2 changed from 1.4.1 to 1.5 so, that java.util.date mapped to xsd:DataTime in 1.4.1 and mapps to xsd:Date after 1.5. That's one of the initial points of this Ticket. As there is a data loss starting with Axis2 1.5 this is clearly a bug and not "Not A Problem" in my opinion. One thing ignored here is the fact, that the behaviour changed between 1.4 and 1.5, so one can't update Axis2 to 1.5 if you rely on having java.util.Date objects being transferred correctly.
          Hide
          Sagara Gunathunga added a comment -

          @David
          My conclusion based on the fact that java.util.Date map to xsd:date, hence according to XMLSchema it's not possible to add hour/minute/second portions. I agree with you that xsd:date<=>java.util.Date loses data but it's a different argument. May be xsd:dateTime<=>java.util.Date can be a appropriate mapping but we need to study impact of this change with community first. If you are interested in start a thread to discuss with others.

          Show
          Sagara Gunathunga added a comment - @David My conclusion based on the fact that java.util.Date map to xsd:date, hence according to XMLSchema it's not possible to add hour/minute/second portions. I agree with you that xsd:date<=>java.util.Date loses data but it's a different argument. May be xsd:dateTime<=>java.util.Date can be a appropriate mapping but we need to study impact of this change with community first. If you are interested in start a thread to discuss with others.
          Hide
          David E. Gelhar added a comment -

          @Sagara - I think you have missed the point of the earlier comments. It's clearly understood that xsd:date does not include hour/minute/second, nobody is saying otherwise. The point is, java.util.Date does include time components, so (a) mapping from xsd:date<=>java.util.Date loses information, and (b) this is a change (and apparently not a well-documented one) in serialization behavior between 1.4 and 1.5.

          I don't think you can reasonably characterize that as "not a problem". It remains a significant trap for a developer who naively includes a java.util.Date member in SOAP method, only to find Axis has discarded some of the data in transit.

          Show
          David E. Gelhar added a comment - @Sagara - I think you have missed the point of the earlier comments. It's clearly understood that xsd:date does not include hour/minute/second, nobody is saying otherwise. The point is, java.util.Date does include time components, so (a) mapping from xsd:date<=>java.util.Date loses information, and (b) this is a change (and apparently not a well-documented one) in serialization behavior between 1.4 and 1.5. I don't think you can reasonably characterize that as "not a problem". It remains a significant trap for a developer who naively includes a java.util.Date member in SOAP method, only to find Axis has discarded some of the data in transit.
          Sagara Gunathunga made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Not A Problem [ 8 ]
          Hide
          Sagara Gunathunga added a comment -

          According to [1]
          date uses the date/timeSevenPropertyModel, with ·hour·, ·minute·, and ·second· required to be absent. ·timezoneOffset· remains ·optional·.

          [1] - http://www.w3.org/TR/xmlschema11-2/#date

          Show
          Sagara Gunathunga added a comment - According to [1] date uses the date/timeSevenPropertyModel, with ·hour·, ·minute·, and ·second· required to be absent. ·timezoneOffset· remains ·optional·. [1] - http://www.w3.org/TR/xmlschema11-2/#date
          Sagara Gunathunga made changes -
          Assignee Sagara Gunathunga [ sagara ]
          Hide
          Oleg Zenzin added a comment - - edited

          Mike, All, thanks for your comments.

          Let me to highlight an issue with current approach, mentioning of it are recurring, but I think from the practical point of view it needs more attention. Both in case of Date and Calendar we have information lost at the transport layer: Date loses its time, Calendar - the style The argument that "the information retrievable from a Calendar is more complete than that retrievable from a Date" is hardly convincing for me as all information we have and can effectively transport is ultimately defined by xsd type. And xsd:dateTime seems to be the most capable / comprehensive. Next would be a question "Which way is the cheapest to transfer that information from / to application level?"

          Please note these considerations are purely from transport layer perspective. But what is Axis2 after all?

          Show
          Oleg Zenzin added a comment - - edited Mike, All, thanks for your comments. Let me to highlight an issue with current approach, mentioning of it are recurring, but I think from the practical point of view it needs more attention. Both in case of Date and Calendar we have information lost at the transport layer: Date loses its time, Calendar - the style The argument that "the information retrievable from a Calendar is more complete than that retrievable from a Date" is hardly convincing for me as all information we have and can effectively transport is ultimately defined by xsd type. And xsd:dateTime seems to be the most capable / comprehensive. Next would be a question "Which way is the cheapest to transfer that information from / to application level?" Please note these considerations are purely from transport layer perspective. But what is Axis2 after all?
          Hide
          Bernhard Schauer added a comment -

          b) One approach could be to serialize all Date types to xs:DateTime cause it seems that this is what they are. On the other side of the communication Axis2 abstractly know what it expects on one side from the wsdl on the other from the Java classes. The format therefore might be parsed with DateFormat.parse() or custom if required to support all possible cases defined in XML specification. I would not parse a java.util.calendar to xs:DateTime as this does not fit in all cases: only when GregorianCalendar is used, cause the calendar used is not contained in the serialized form. Thus I'd serialize java.util.Calendar custom or as xs:DateTime but then converted to a Gregorian formatted date, as ISO defines the international dates as Gregorian ones. The latter one would require a data change and thus is needed to be documented (to be seen in README file or Homepage).

          I know that there is currently just the GregorianCalendar implemented, but the Java "design" is not limited to. As more calendar systems may be supported in future, I'd appreciate a clean implementation and not a "quick and dirty" one.

          Show
          Bernhard Schauer added a comment - b) One approach could be to serialize all Date types to xs:DateTime cause it seems that this is what they are. On the other side of the communication Axis2 abstractly know what it expects on one side from the wsdl on the other from the Java classes. The format therefore might be parsed with DateFormat.parse() or custom if required to support all possible cases defined in XML specification. I would not parse a java.util.calendar to xs:DateTime as this does not fit in all cases: only when GregorianCalendar is used, cause the calendar used is not contained in the serialized form. Thus I'd serialize java.util.Calendar custom or as xs:DateTime but then converted to a Gregorian formatted date, as ISO defines the international dates as Gregorian ones. The latter one would require a data change and thus is needed to be documented (to be seen in README file or Homepage). I know that there is currently just the GregorianCalendar implemented, but the Java "design" is not limited to. As more calendar systems may be supported in future, I'd appreciate a clean implementation and not a "quick and dirty" one.
          Hide
          Bernhard Schauer added a comment -

          a) Mike, documented in my opinion means "on the Axis2 project page" - either in a changelog or better in the empty section "Known Issues and Limitations" cause this is clearly a limitation. I think that putting an Axis specific annotation is neither a good solution nor required. Additionally I liked to add that if a Java datatype like java.util.Date contains or may contain date, time and timezone that a developer will expect the same data after serialization and deserialization, cause by definition packaging something for transport does not include changing the package content. Only customs would do that.

          Show
          Bernhard Schauer added a comment - a) Mike, documented in my opinion means "on the Axis2 project page" - either in a changelog or better in the empty section "Known Issues and Limitations" cause this is clearly a limitation. I think that putting an Axis specific annotation is neither a good solution nor required. Additionally I liked to add that if a Java datatype like java.util.Date contains or may contain date, time and timezone that a developer will expect the same data after serialization and deserialization, cause by definition packaging something for transport does not include changing the package content. Only customs would do that.
          Hide
          Mike added a comment -

          Oleg, this was reported here: https://issues.apache.org/jira/browse/AXIS2-4544 and is already fixed in 1.5.1

          Show
          Mike added a comment - Oleg, this was reported here: https://issues.apache.org/jira/browse/AXIS2-4544 and is already fixed in 1.5.1
          Hide
          Mike added a comment -

          Bernhard, in fact it is, well at least mentioned here: http://amilachinthaka.blogspot.com/2009/09/handling-date-and-datetime-with-axis2.html
          as for letting Java's classes parse the string, how would you generate the wsdl then? That is what type should axis2 put into the wsdl if it does not know how it will be parsed?
          I personally think it would be awesome to have an annotation that would tell axis2 how to treat the Date.

          Show
          Mike added a comment - Bernhard, in fact it is, well at least mentioned here: http://amilachinthaka.blogspot.com/2009/09/handling-date-and-datetime-with-axis2.html as for letting Java's classes parse the string, how would you generate the wsdl then? That is what type should axis2 put into the wsdl if it does not know how it will be parsed? I personally think it would be awesome to have an annotation that would tell axis2 how to treat the Date.
          Hide
          Mauro Molinari added a comment -

          I think the changes were made because there were other things broken in Axis2 pre-1.5 date manipulations (I had issues in 1.3, for instance, solved with 1.5... never tried 1.4).

          I agree that the break in backward compatibility is very bad. This is also my fear, so I hope that any intervention that may be made in 1.5 to fix bugs in this area does not break compatibility again.

          Show
          Mauro Molinari added a comment - I think the changes were made because there were other things broken in Axis2 pre-1.5 date manipulations (I had issues in 1.3, for instance, solved with 1.5... never tried 1.4). I agree that the break in backward compatibility is very bad. This is also my fear, so I hope that any intervention that may be made in 1.5 to fix bugs in this area does not break compatibility again.
          Hide
          Bernhard Schauer added a comment -

          Mauro, I agree that this might be a convention, but there might be situations where you simply can't change the data types that easy. It's not a good practice to change the serialization between two versions without documenting it anywhere. It took me a lot of time to find out why something working with 1.4 does not in 1.5.
          Anyway one of the above mentioned issues also was that Axis2 was not able to deserialize on client side what it has serialized on server side (@see: Thomas Raddatz' comment) - this was also my issue here. I think there should be a better solution for that, maybe checking a xml date string via regex and then let the Java's classes parse that String or whatever.

          Show
          Bernhard Schauer added a comment - Mauro, I agree that this might be a convention, but there might be situations where you simply can't change the data types that easy. It's not a good practice to change the serialization between two versions without documenting it anywhere. It took me a lot of time to find out why something working with 1.4 does not in 1.5. Anyway one of the above mentioned issues also was that Axis2 was not able to deserialize on client side what it has serialized on server side (@see: Thomas Raddatz' comment) - this was also my issue here. I think there should be a better solution for that, maybe checking a xml date string via regex and then let the Java's classes parse that String or whatever.
          Hide
          Mauro Molinari added a comment -

          Given that the API Java provides for time and date manipulations are awful (from a practical point of view), the Axis2 mapping of xsd:date<=>java.util.Date and xsd:dateTime<=>java.util.Calendar is nothing more than a convention. So, once you know this convention, I still can't understand why you want to map Date with xsd:dateTime at all costs, given that it's quite easy to get a Date from a Calendar and viceversa.

          I think the reason behind this choice is just a good sense thought that if someone chooses xsd:dateTime he may be trying to express an information which is more accurate than the case he chooses xsd:date... and of course the information retrievable from a Calendar is more complete than that retrievable from a Date. So I think this is the most natural choice, without the useless complication of having two Java types that could be equally used interchangeably in theory.

          Actually, the real problem for me is that Axis2 documentation is very poor: it should be clearly written somewhere what the mapping convention is and not only on Amila's blog (I'm talking about the link Amila sometimes points users to regarding this issue).

          This is my own opinion, although, of course, it's always possible to do better (i.e.: support Joda Time or JSR-310, as Pétur suggested) and to correct bugs if there are legal cases not covered by the conversion utils, as the last comment seems to point out.

          Show
          Mauro Molinari added a comment - Given that the API Java provides for time and date manipulations are awful (from a practical point of view), the Axis2 mapping of xsd:date<=>java.util.Date and xsd:dateTime<=>java.util.Calendar is nothing more than a convention. So, once you know this convention, I still can't understand why you want to map Date with xsd:dateTime at all costs, given that it's quite easy to get a Date from a Calendar and viceversa. I think the reason behind this choice is just a good sense thought that if someone chooses xsd:dateTime he may be trying to express an information which is more accurate than the case he chooses xsd:date... and of course the information retrievable from a Calendar is more complete than that retrievable from a Date. So I think this is the most natural choice, without the useless complication of having two Java types that could be equally used interchangeably in theory. Actually, the real problem for me is that Axis2 documentation is very poor: it should be clearly written somewhere what the mapping convention is and not only on Amila's blog (I'm talking about the link Amila sometimes points users to regarding this issue). This is my own opinion, although, of course, it's always possible to do better (i.e.: support Joda Time or JSR-310, as Pétur suggested) and to correct bugs if there are legal cases not covered by the conversion utils, as the last comment seems to point out.
          Hide
          Oleg Zenzin added a comment -

          Btw, from the source code of SimpleTypeMapper and ConverterUtil#convertToDateTime it does expect not less than 19 character string, throwing NumberFormatException("date string can not be less than 19 charactors"). Which is not consistent with xsd:date lexical representation: "''? yyyy '' mm '-' dd zzzzzz?".

          So, there's a bug, I think.

          Show
          Oleg Zenzin added a comment - Btw, from the source code of SimpleTypeMapper and ConverterUtil#convertToDateTime it does expect not less than 19 character string, throwing NumberFormatException("date string can not be less than 19 charactors"). Which is not consistent with xsd:date lexical representation: "' '? yyyy ' ' mm '-' dd zzzzzz?". So, there's a bug, I think.
          Hide
          Oleg Zenzin added a comment -

          I cannot agree with Mauro. Here's the very first line from Sun Java API for each class:
          "The Calendar class is an abstract class that provides methods for converting..."
          "The class Date represents a specific instant in time, with millisecond precision..."

          Second, according to specification "XML Schema Part 2: Datatypes..." both types (xsd:dateTime and xsd:date ) have optional timezone field. Why keeping java.util.Date for xsd:date and not allowing it for xsd:dateTime than?

          Third: mapping java.util.Date to xsd:date actually makes the information (time part) being lost! Any reasoning behind this?

          Forth: there's nothing in xsd:dateTime lexical representation as compared to xsd:date which makes you lean towards Calendar versus Date. Indeed the only difference is that it omits time part ("let the "date portion" of a dateTime or date object be an object similar to a dateTime or date object, with similar year, month, and day properties, but no others, having the same value for these properties as the original dateTime or date object").

          Having two mappings for date in general case looks overwhelming. And looking to SQL mappings, I'd rather leave Date, at least it's more intuitive...

          Show
          Oleg Zenzin added a comment - I cannot agree with Mauro. Here's the very first line from Sun Java API for each class: "The Calendar class is an abstract class that provides methods for converting..." "The class Date represents a specific instant in time, with millisecond precision..." Second, according to specification "XML Schema Part 2: Datatypes..." both types (xsd:dateTime and xsd:date ) have optional timezone field. Why keeping java.util.Date for xsd:date and not allowing it for xsd:dateTime than? Third: mapping java.util.Date to xsd:date actually makes the information (time part) being lost! Any reasoning behind this? Forth: there's nothing in xsd:dateTime lexical representation as compared to xsd:date which makes you lean towards Calendar versus Date. Indeed the only difference is that it omits time part ("let the "date portion" of a dateTime or date object be an object similar to a dateTime or date object, with similar year, month, and day properties, but no others, having the same value for these properties as the original dateTime or date object"). Having two mappings for date in general case looks overwhelming. And looking to SQL mappings, I'd rather leave Date, at least it's more intuitive...
          Bernhard Schauer made changes -
          Link This issue relates to AXIS2-4626 [ AXIS2-4626 ]
          Hide
          Pétur Runólfsson added a comment -

          I fully agree that java.util.Date is not the best way to manage date/time values. However, it is equally bad whether the time is included or not. I don't see how the lack of time zone has any effect on the choice between xs:date and xs:dateTime, a time zone is optional for both of those types. If fact, the xml schema type that is the closest match for java.util.Date is a xs:dateTime without a time zone.

          Xml schema has a bunch of date/time types, most of which don't have any good match in java.util. If Axis2 is to support xml types other xs:dateTime, I don't think the way to go is to arbitrarily assign Java types to xml types. Instead, Axis2 should allow users to specify types to use (for example Joda-time or JSR-310) along with mappings and formatting/parsing functions. If JSR-310 is approved, it would of course make sense for Axis2 to support it directly.

          Show
          Pétur Runólfsson added a comment - I fully agree that java.util.Date is not the best way to manage date/time values. However, it is equally bad whether the time is included or not. I don't see how the lack of time zone has any effect on the choice between xs:date and xs:dateTime, a time zone is optional for both of those types. If fact, the xml schema type that is the closest match for java.util.Date is a xs:dateTime without a time zone. Xml schema has a bunch of date/time types, most of which don't have any good match in java.util. If Axis2 is to support xml types other xs:dateTime, I don't think the way to go is to arbitrarily assign Java types to xml types. Instead, Axis2 should allow users to specify types to use (for example Joda-time or JSR-310) along with mappings and formatting/parsing functions. If JSR-310 is approved, it would of course make sense for Axis2 to support it directly.
          Hide
          Mauro Molinari added a comment -

          I don't know what's going on in your case, we're using xsd:date without problems in Axis2 1.5.

          Looking at the provided stack trace, it seems that there's a conversion towards Calendar from what is expected to be a xsd:dateTime (org.apache.axis2.databinding.utils.ConverterUtil.convertToDateTime is called), while your input is a xsd:date instead: are you sure your WSDL and your Java classes to which you're mapping are correct? xsd:dateTime should be mapped to Calendar (and viceversa), while xsd:date should be mapped to Date (and vice-versa). In your case, it seems that a SOAP envelope with a xsd:date is being converted into a Calendar, instead of Date. Maybe you changed your WSDL and you forgot to re-generate the MessageReceiver classes?

          Show
          Mauro Molinari added a comment - I don't know what's going on in your case, we're using xsd:date without problems in Axis2 1.5. Looking at the provided stack trace, it seems that there's a conversion towards Calendar from what is expected to be a xsd:dateTime (org.apache.axis2.databinding.utils.ConverterUtil.convertToDateTime is called), while your input is a xsd:date instead: are you sure your WSDL and your Java classes to which you're mapping are correct? xsd:dateTime should be mapped to Calendar (and viceversa), while xsd:date should be mapped to Date (and vice-versa). In your case, it seems that a SOAP envelope with a xsd:date is being converted into a Calendar, instead of Date. Maybe you changed your WSDL and you forgot to re-generate the MessageReceiver classes?
          Hide
          Thomas Raddatz added a comment -

          Mauro, I completely agree with you. Given that someone specifies xs:date in a WSDL file he most likely what to transport a date without a time portion. However there seems to be an error when Axis 2 v1.5 receives a xs:date. In that case it complains that a "date string can not be less than 19 charactors".

          Axis2 version information:

          Found Apache-Axis (org.apache.axis2.transport.http.AxisServlet)
          at C:\Jako 2009\Tomcat\webapps\axis2\WEB-INF\lib\axis2-transport-http-1.5.jar
          Found Jakarta-Commons Logging (org.apache.commons.logging.Log)
          at C:\Jako 2009\Tomcat\webapps\axis2\WEB-INF\lib\commons-logging-1.1.1.jar
          Found Streaming API for XML (javax.xml.stream.XMLStreamReader)
          at C:\Jako 2009\Tomcat\webapps\axis2\WEB-INF\lib\geronimo-stax-api_1.0_spec-1.0.1.jar
          Found Streaming API for XML implementation (org.codehaus.stax2.XMLStreamWriter2)
          at C:\Jako 2009\Tomcat\webapps\axis2\WEB-INF\lib\wstx-asl-3.2.4.jar

          Date sent: <xsd:date>2009-10-08</xsd:date>

          On the fly WSDL file:

          <xs:complexType name="DataTypesResponse">
          <xs:sequence>
          <xs:element minOccurs="0" name="bigInteger" nillable="true" type="xs:long"/>
          <xs:element minOccurs="0" name="bool" nillable="true" type="xs:boolean"/>
          <xs:element minOccurs="0" name="date" nillable="true" type="xs:date"/>
          <xs:element minOccurs="0" name="doubleFloat" nillable="true" type="xs:double"/>
          <xs:element minOccurs="0" name="integer" nillable="true" type="xs:int"/>
          <xs:element minOccurs="0" name="packed" nillable="true" type="xs:decimal"/>
          <xs:element minOccurs="0" name="singleFloat" nillable="true" type="xs:float"/>
          <xs:element minOccurs="0" name="smallInteger" nillable="true" type="xs:short"/>
          <xs:element minOccurs="0" name="string" nillable="true" type="xs:string"/>
          <xs:element minOccurs="0" name="time" nillable="true" type="xs:dateTime"/>
          <xs:element minOccurs="0" name="timestamp" nillable="true" type="xs:dateTime"/>

          <xs:element minOccurs="0" name="zoned" nillable="true" type="xs:decimal"/>
          </xs:sequence>
          </xs:complexType>
          <xs:complexType name="DataTypesRequest">
          <xs:complexContent>
          <xs:extension base="ax21:DataTypesResponse">
          <xs:sequence/>
          </xs:extension>
          </xs:complexContent>

          </xs:complexType>

          Stack trace:

          [ERROR] date string can not be less than 19 charactors
          java.lang.NumberFormatException: date string can not be less than 19 charactors
          at org.apache.axis2.databinding.utils.ConverterUtil.convertToDateTime(ConverterUtil.java:993)
          at org.apache.axis2.databinding.typemapping.SimpleTypeMapper.makeCalendar(SimpleTypeMapper.java:309)
          at org.apache.axis2.databinding.typemapping.SimpleTypeMapper.getSimpleTypeObject(SimpleTypeMapper.java:112)
          at org.apache.axis2.databinding.utils.BeanUtil.deserialize(BeanUtil.java:397)
          at org.apache.axis2.databinding.utils.BeanUtil.processObject(BeanUtil.java:682)
          at org.apache.axis2.databinding.utils.BeanUtil.ProcessElement(BeanUtil.java:630)
          at org.apache.axis2.databinding.utils.BeanUtil.deserialize(BeanUtil.java:562)
          at org.apache.axis2.rpc.receivers.RPCUtil.processRequest(RPCUtil.java:153)
          at org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:188)
          at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:102)
          at org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
          at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
          at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
          at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
          at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
          at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
          at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
          at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
          at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
          at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
          at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
          at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
          at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
          at java.lang.Thread.run(Thread.java:595)
          [ERROR] date string can not be less than 19 charactors
          org.apache.axis2.AxisFault: date string can not be less than 19 charactors
          at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430)
          at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:161)
          at org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
          at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
          at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
          at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
          at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
          at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
          at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
          at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
          at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
          at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
          at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
          at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
          at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
          at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
          at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
          at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
          at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
          at java.lang.Thread.run(Thread.java:595)
          Caused by: java.lang.NumberFormatException: date string can not be less than 19 charactors
          at org.apache.axis2.databinding.utils.ConverterUtil.convertToDateTime(ConverterUtil.java:993)
          at org.apache.axis2.databinding.typemapping.SimpleTypeMapper.makeCalendar(SimpleTypeMapper.java:309)
          at org.apache.axis2.databinding.typemapping.SimpleTypeMapper.getSimpleTypeObject(SimpleTypeMapper.java:112)
          at org.apache.axis2.databinding.utils.BeanUtil.deserialize(BeanUtil.java:397)
          at org.apache.axis2.databinding.utils.BeanUtil.processObject(BeanUtil.java:682)
          at org.apache.axis2.databinding.utils.BeanUtil.ProcessElement(BeanUtil.java:630)
          at org.apache.axis2.databinding.utils.BeanUtil.deserialize(BeanUtil.java:562)
          at org.apache.axis2.rpc.receivers.RPCUtil.processRequest(RPCUtil.java:153)
          at org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:188)
          at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:102)
          ... 19 more

          Show
          Thomas Raddatz added a comment - Mauro, I completely agree with you. Given that someone specifies xs:date in a WSDL file he most likely what to transport a date without a time portion. However there seems to be an error when Axis 2 v1.5 receives a xs:date. In that case it complains that a "date string can not be less than 19 charactors". Axis2 version information: Found Apache-Axis (org.apache.axis2.transport.http.AxisServlet) at C:\Jako 2009\Tomcat\webapps\axis2\WEB-INF\lib\axis2-transport-http-1.5.jar Found Jakarta-Commons Logging (org.apache.commons.logging.Log) at C:\Jako 2009\Tomcat\webapps\axis2\WEB-INF\lib\commons-logging-1.1.1.jar Found Streaming API for XML (javax.xml.stream.XMLStreamReader) at C:\Jako 2009\Tomcat\webapps\axis2\WEB-INF\lib\geronimo-stax-api_1.0_spec-1.0.1.jar Found Streaming API for XML implementation (org.codehaus.stax2.XMLStreamWriter2) at C:\Jako 2009\Tomcat\webapps\axis2\WEB-INF\lib\wstx-asl-3.2.4.jar Date sent: <xsd:date>2009-10-08</xsd:date> On the fly WSDL file: <xs:complexType name="DataTypesResponse"> <xs:sequence> <xs:element minOccurs="0" name="bigInteger" nillable="true" type="xs:long"/> <xs:element minOccurs="0" name="bool" nillable="true" type="xs:boolean"/> <xs:element minOccurs="0" name="date" nillable="true" type="xs:date"/> <xs:element minOccurs="0" name="doubleFloat" nillable="true" type="xs:double"/> <xs:element minOccurs="0" name="integer" nillable="true" type="xs:int"/> <xs:element minOccurs="0" name="packed" nillable="true" type="xs:decimal"/> <xs:element minOccurs="0" name="singleFloat" nillable="true" type="xs:float"/> <xs:element minOccurs="0" name="smallInteger" nillable="true" type="xs:short"/> <xs:element minOccurs="0" name="string" nillable="true" type="xs:string"/> <xs:element minOccurs="0" name="time" nillable="true" type="xs:dateTime"/> <xs:element minOccurs="0" name="timestamp" nillable="true" type="xs:dateTime"/> <xs:element minOccurs="0" name="zoned" nillable="true" type="xs:decimal"/> </xs:sequence> </xs:complexType> <xs:complexType name="DataTypesRequest"> <xs:complexContent> <xs:extension base="ax21:DataTypesResponse"> <xs:sequence/> </xs:extension> </xs:complexContent> </xs:complexType> Stack trace: [ERROR] date string can not be less than 19 charactors java.lang.NumberFormatException: date string can not be less than 19 charactors at org.apache.axis2.databinding.utils.ConverterUtil.convertToDateTime(ConverterUtil.java:993) at org.apache.axis2.databinding.typemapping.SimpleTypeMapper.makeCalendar(SimpleTypeMapper.java:309) at org.apache.axis2.databinding.typemapping.SimpleTypeMapper.getSimpleTypeObject(SimpleTypeMapper.java:112) at org.apache.axis2.databinding.utils.BeanUtil.deserialize(BeanUtil.java:397) at org.apache.axis2.databinding.utils.BeanUtil.processObject(BeanUtil.java:682) at org.apache.axis2.databinding.utils.BeanUtil.ProcessElement(BeanUtil.java:630) at org.apache.axis2.databinding.utils.BeanUtil.deserialize(BeanUtil.java:562) at org.apache.axis2.rpc.receivers.RPCUtil.processRequest(RPCUtil.java:153) at org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:188) at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:102) at org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40) at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:595) [ERROR] date string can not be less than 19 charactors org.apache.axis2.AxisFault: date string can not be less than 19 charactors at org.apache.axis2.AxisFault.makeFault(AxisFault.java:430) at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:161) at org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40) at org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167) at org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.NumberFormatException: date string can not be less than 19 charactors at org.apache.axis2.databinding.utils.ConverterUtil.convertToDateTime(ConverterUtil.java:993) at org.apache.axis2.databinding.typemapping.SimpleTypeMapper.makeCalendar(SimpleTypeMapper.java:309) at org.apache.axis2.databinding.typemapping.SimpleTypeMapper.getSimpleTypeObject(SimpleTypeMapper.java:112) at org.apache.axis2.databinding.utils.BeanUtil.deserialize(BeanUtil.java:397) at org.apache.axis2.databinding.utils.BeanUtil.processObject(BeanUtil.java:682) at org.apache.axis2.databinding.utils.BeanUtil.ProcessElement(BeanUtil.java:630) at org.apache.axis2.databinding.utils.BeanUtil.deserialize(BeanUtil.java:562) at org.apache.axis2.rpc.receivers.RPCUtil.processRequest(RPCUtil.java:153) at org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:188) at org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:102) ... 19 more
          Hide
          Mauro Molinari added a comment -

          I think that Axis2 1.5 does the assumption that:

          • if I want to work just with the date I use java.util.Date => so it is mapped to xsd:date
          • if I want to work with date and time I use java.util.Calendar => so it is mapped to xsd:dateTime

          java.util.Date is not the best way to manage date/time values (for instance, it does not handle time zones), except if you use it as container to transport a time instant previously determined using a Calendar (a plain long number would give the same functionality, though).

          I quite agree with the choice Axis2 1.5 does, so I don't think this is a "bug", although it breaks your code because of Axis2 1.4.1 different behaviour.

          I would like to hear the opinion of the Axis2 developers on this.

          Mauro.

          Show
          Mauro Molinari added a comment - I think that Axis2 1.5 does the assumption that: if I want to work just with the date I use java.util.Date => so it is mapped to xsd:date if I want to work with date and time I use java.util.Calendar => so it is mapped to xsd:dateTime java.util.Date is not the best way to manage date/time values (for instance, it does not handle time zones), except if you use it as container to transport a time instant previously determined using a Calendar (a plain long number would give the same functionality, though). I quite agree with the choice Axis2 1.5 does, so I don't think this is a "bug", although it breaks your code because of Axis2 1.4.1 different behaviour. I would like to hear the opinion of the Axis2 developers on this. Mauro.
          Andreas Veithen made changes -
          Link This issue relates to AXIS2-4075 [ AXIS2-4075 ]
          Pétur Runólfsson made changes -
          Attachment Server-1.4.1.wsdl [ 12410324 ]
          Attachment Server-1.5.wsdl [ 12410325 ]
          Hide
          Pétur Runólfsson added a comment -

          Attached wsdl files generated by 1.4.1 and 1.5. The return type in 1.4.1 is xs:dateTime, but in 1.5 it has changed to xs:date. The value returned is in both cases correct according to the schema, the problem is that the change of return type means that information returned by the web service gets lost on it's way to the client.

          Show
          Pétur Runólfsson added a comment - Attached wsdl files generated by 1.4.1 and 1.5. The return type in 1.4.1 is xs:dateTime, but in 1.5 it has changed to xs:date. The value returned is in both cases correct according to the schema, the problem is that the change of return type means that information returned by the web service gets lost on it's way to the client.
          Hide
          Pétur Runólfsson added a comment -

          This is request used to get the responses above:

          <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
          <soap:Header/>
          <soap:Body/>
          </soap:Envelope>

          Show
          Pétur Runólfsson added a comment - This is request used to get the responses above: <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Header/> <soap:Body/> </soap:Envelope>
          Pétur Runólfsson made changes -
          Field Original Value New Value
          Attachment Server.java [ 12410322 ]
          Attachment services.xml [ 12410323 ]
          Hide
          Pétur Runólfsson added a comment -

          Attached POJO web service used to demonstrate problem.

          Show
          Pétur Runólfsson added a comment - Attached POJO web service used to demonstrate problem.
          Pétur Runólfsson created issue -

            People

            • Assignee:
              Sagara Gunathunga
              Reporter:
              Pétur Runólfsson
            • Votes:
              8 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development