[
https://issues.apache.org/jira/browse/OLINGO-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16148508#comment-16148508
]
Punith DG commented on OLINGO-1173:
-----------------------------------
{{Hi,
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.
Thanks,
Punith
}}
> 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
>
> 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)
