olingo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Punith DG (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OLINGO-1173) CLONE - EdmDateTime format validation while parsing
Date Thu, 31 Aug 2017 06:20:00 GMT

     [ https://issues.apache.org/jira/browse/OLINGO-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Punith DG updated OLINGO-1173:
    Attachment: EdmDateTime.java

Comments are transforming to emoticans. Attached the fix java source file.

> CLONE - EdmDateTime format validation while parsing
> ---------------------------------------------------
>                 Key: OLINGO-1173
>                 URL: https://issues.apache.org/jira/browse/OLINGO-1173
>             Project: Olingo
>          Issue Type: Question
>          Components: odata2-core
>    Affects Versions: V2 2.0.6
>            Reporter: Punith DG
>            Assignee: Christian Amend
>         Attachments: EdmDateTime.java
> 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
> 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

View raw message