[jira] [Commented] (OLINGO-928) EdmDateTime format validation while parsing

["Christian Amend (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OLINGO-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15239076#comment-15239076 ] 

Christian Amend commented on OLINGO-928:
----------------------------------------

Hi Rahul,

We expected the servers to be OData compliant. The only switch we provided is for facet validation in case the server sends data which does not follow the max-length facet for example. so:
1) No. We only have a switch for facet validation.
2) We did not allow to override this bahviour as we thought a server is sending properly formed data
3) It certainly prevents you from working with the library as a client so I would see this as an issue especially as there is no way to work around this. But I would see this issue primarily at the microsoft server.
4) Since this is the first time the issue comes up we have no plan on how to handle this. Also the communities focus is currently on OData V4 so I don`t know when we can provide a fix. If you would like to contribute here is a guide: http://olingo.apache.org/contribute.html

Best Regards,
Chris

> 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
>
> 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.3.4#6332)