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] [Commented] (OLINGO-928) EdmDateTime format validation while parsing
Date Wed, 30 Aug 2017 14:42:00 GMT

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

Punith DG commented on OLINGO-928:


I see this precision issue is solved in 2.0.9 build. But still there is an issue. It doesn't
match the date time which contains Z at end. e.g., 2016-03-22T08:36:24Z

If we add a match to allow Z at the end, it would solve the issue completely. It is a very
small fix so I think you won't mind fixing this.

Current regex - (\\p{Digit}{1,4})-(\\p{Digit}{1,2})-(\\p{Digit}{1,2})T(\\p{Digit}{1,2}):(\\p{Digit}{1,2})(?::(\\p{Digit}{1,2})(\\.(\\p{Digit}{0,9}?)0*)?)?

Fix regex - (\\p{Digit}{1,4})-(\\p{Digit}{1,2})-(\\p{Digit}{1,2})T(\\p{Digit}{1,2}):(\\p{Digit}{1,2})(?::(\\p{Digit}{1,2})(\\.(\\p{Digit}{0,9}?)0*)?[zZ]?)?

Please consider this change though it's small. This is affecting many prominent OData offering
backends like Microsoft and SAP.


> 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
> 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