Mailing-List: contact dev-help@olingo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@olingo.apache.org
Date: Thu, 31 Aug 2017 06:20:00 +0000 (UTC)
From: "Punith DG (JIRA)" <jira@apache.org>
To: dev@olingo.apache.org
Message-ID: <JIRA.13098739.1504159908000.167079.1504160400947@Atlassian.JIRA>
In-Reply-To: <JIRA.13098739.1504159908000@Atlassian.JIRA>
References: <JIRA.13098739.1504159908000@Atlassian.JIRA> <JIRA.13098739.1504159908084@jira-lw-us.apache.org>
Subject: [jira] [Updated] (OLINGO-1173) CLONE - EdmDateTime format
 validation while parsing
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 31 Aug 2017 06:20:10 -0000


     [ https://issues.apache.org/jira/browse/OLINGO-1173?page=3Dcom.atlassi=
an.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=20
> 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=20
> e.g.
> <d:CreatedOn m:type=3D"Edm.DateTime">2016-03-22T08:36:24Z</d:CreatedOn> d=
ata 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 ex=
act same format that of the primitive types supported by OData. As defined =
here http://www.odata.org/documentation/odata-version-2-0/overview/#Abstrac=
tTypeSystem
> So this way an EdmDateTime should be always of this type --> 2000-12-12T1=
2: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(EdmDa=
teTime.java:116)
>       at org.apache.olingo.odata2.core.edm.EdmDateTime.internalValueOfStr=
ing(EdmDateTime.java:91)
>       at org.apache.olingo.odata2.core.edm.AbstractSimpleType.valueOfStri=
ng(AbstractSimpleType.java:91)
>       at org.apache.olingo.odata2.core.ep.consumer.XmlPropertyConsumer.co=
nvert(XmlPropertyConsumer.java:206)
>       at org.apache.olingo.odata2.core.ep.consumer.XmlPropertyConsumer.re=
adStartedElement(XmlPropertyConsumer.java:192)
>       at org.apache.olingo.odata2.core.ep.consumer.XmlEntryConsumer.readP=
roperties(XmlEntryConsumer.java:591)
>       at org.apache.olingo.odata2.core.ep.consumer.XmlEntryConsumer.readC=
ontent(XmlEntryConsumer.java:544)
>       at org.apache.olingo.odata2.core.ep.consumer.XmlEntryConsumer.handl=
eStartedTag(XmlEntryConsumer.java:137)
>       at org.apache.olingo.odata2.core.ep.consumer.XmlEntryConsumer.readE=
ntry(XmlEntryConsumer.java:89)
> As a consumer/client this is stopping us from using a major part of the A=
PI specially query.=20
> Question:
> 1) Is there any kind of configuration in olingo that allows olingo client=
s 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.apac=
he.olingo.odata2.core.edm)
>      As org.apache.olingo.odata2.core.edm.EdmDateTime.parseLiteral(String=
, EdmFacets, Calendar) being a static method. Looks like you don=E2=80=99t =
want anyone to override them.
> 3) Do you regard this as an issue or is it Working as design ? If it is w=
orking as designed, then is there a way to work around this, =20
>    so that as a client we will still be able to parse wrong formatted dat=
a?
> 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)