[
https://issues.apache.org/jira/browse/OLINGO-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143808#comment-16143808
]
Punith DG commented on OLINGO-928:
----------------------------------
Hi Amend,
I'm facing the same issue with SAP C4C OData. The parser is failing to get read
the DateTime values.
Can we have a re-look at this issue?
Thanks,
Punith
> EdmDateTime format validation while parsing
> -------------------------------------------
>
> Key: OLINGO-928
> URL: https://issues.apache.org/jira/browse/OLINGO-928
> Project: Olingo
> Issue Type: Question
> Components: odata2-core
> Affects Versions: V2 2.0.6
> Reporter: Rahuldeb Barman
> Assignee: Christian Amend
>
> Hi Olingo Dev,
> I am using olingo(for OData2 ) as a client to access some OData providers'
> APIs .
> I am using below jars
> olingo-odata2-core-2.0.6.jar
> olingo-odata2-api-2.0.6.jar
> Olingo fails to parse the EdmDateTime field when the OData provider sends it
> with a wrong data format
> e.g.
> <d:CreatedOn m:type="Edm.DateTime">2016-03-22T08:36:24Z</d:CreatedOn> data
> for a Edm.DateTime field.
> Microsoft dynamics CRM sends all its EdmDateTime in this wrong format.
> Form the olingo code it looks like you force the data type to have the exact
> same format that of the primitive types supported by OData. As defined here
> http://www.odata.org/documentation/odata-version-2-0/overview/#AbstractTypeSystem
> So this way an EdmDateTime should be always of this type --> 2000-12-12T12:00
> while parsing this date we are getting below exception
> Caused by: org.apache.olingo.odata2.api.edm.EdmSimpleTypeException: The
> literal '2016-04-04T21:53:44Z' is not formatted properly.
> at
> org.apache.olingo.odata2.core.edm.EdmDateTime.parseLiteral(EdmDateTime.java:116)
> at
> org.apache.olingo.odata2.core.edm.EdmDateTime.internalValueOfString(EdmDateTime.java:91)
> at
> org.apache.olingo.odata2.core.edm.AbstractSimpleType.valueOfString(AbstractSimpleType.java:91)
> at
> org.apache.olingo.odata2.core.ep.consumer.XmlPropertyConsumer.convert(XmlPropertyConsumer.java:206)
> at
> org.apache.olingo.odata2.core.ep.consumer.XmlPropertyConsumer.readStartedElement(XmlPropertyConsumer.java:192)
> at
> org.apache.olingo.odata2.core.ep.consumer.XmlEntryConsumer.readProperties(XmlEntryConsumer.java:591)
> at
> org.apache.olingo.odata2.core.ep.consumer.XmlEntryConsumer.readContent(XmlEntryConsumer.java:544)
> at
> org.apache.olingo.odata2.core.ep.consumer.XmlEntryConsumer.handleStartedTag(XmlEntryConsumer.java:137)
> at
> org.apache.olingo.odata2.core.ep.consumer.XmlEntryConsumer.readEntry(XmlEntryConsumer.java:89)
> As a consumer/client this is stopping us from using a major part of the API
> specially query.
> Question:
> 1) Is there any kind of configuration in olingo that allows olingo clients to
> avoid this validation ?
> 2) Is there any way I can override those classes to relax validation?
> I do not see any way to override EdmDateTime class (package
> org.apache.olingo.odata2.core.edm)
> As org.apache.olingo.odata2.core.edm.EdmDateTime.parseLiteral(String,
> EdmFacets, Calendar) being a static method. Looks like you don’t want anyone
> to override them.
> 3) Do you regard this as an issue or is it Working as design ? If it is
> working as designed, then is there a way to work around this,
> so that as a client we will still be able to parse wrong formatted data?
> 4) If there is no step taken yet and in case it is a well-known issue(?), is
> there any near future plan to address this issue ?
> Thanks,
> Rahul
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
