castor
  1. castor
  2. CASTOR-2017

Bogus offset in timestamp causes java.lang.ArrayIndexOutOfBoundsException while unmarshalling

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.1
    • Fix Version/s: 1.1.2
    • Component/s: XML
    • Labels:
      None
    • Environment:
      Java 1.4.2
    • Number of attachments :
      1

      Description

      We have an element that is a Timestamp defined in a complex type like this.

      <xs:element name="ContainingElement">
      <xs:complexType>
      <xs:sequence>
      <xs:element name="SomeElement" type="xs:string" minOccurs="0"/>
      <!-- ... more elements -->
      <xs:element ref="SomeReference" minOccurs="0"/>
      <!-- ... more references -->
      <xs:element name="Timestamp" type="xs:dateTime" minOccurs="0"/>
      <!-- ... more elements -->
      <!-- ... more references -->
      </xs:sequence>
      </xs:complexType>
      </xs:element>

      We generate classes with the code generator.

      We create an unmarshaller, turn off validation, and try to unmarshall the following bogus input. The last two digits are 44 instead of 00.

      <ContainingElement>
      <SomeElement>
      <!-- ... more elements etc... -->
      <Timestamp>2006-08-29T08:50:00.0-03:44</Timestamp>
      <!-- ... more elements etc... -->
      </ContainingElement>

      Castor then bombs with an ArrayIndexOutOfBoundsException. We tried turning on validation, but the error still persists.

      java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 0
      at org.exolab.castor.types.DateTimeBase.setDateFormatTimeZone(DateTimeBase.java:1318)
      at org.exolab.castor.types.DateTime.toDate(DateTime.java:185)
      at org.exolab.castor.xml.handlers.DateFieldHandler.parse(DateFieldHandler.java:368)
      at org.exolab.castor.xml.handlers.DateFieldHandler.setValue(DateFieldHandler.java:166)
      at org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:1054)
      at org.exolab.castor.xml.UnmarshalHandler.endElement(UnmarshalHandler.java:1119)
      at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source)
      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
      at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
      at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
      at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
      at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
      at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
      at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:729)
      at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:621)

      Other bad timestamps produce a meaningful error message in Castor, and this should too. If we fix the input and make the offset be "3:00" e.g.

      <ContainingElement>
      <SomeElement>
      <!-- ... more elements etc... -->
      <Timestamp>2006-08-29T08:50:00.0-03:00</Timestamp>
      <!-- ... more elements etc... -->
      </ContainingElement>

      Things work just fine.

      Thanks for all the fish.

        Activity

          People

          • Assignee:
            Werner Guttmann
            Reporter:
            Bill Robertson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 20 minutes
              20m