[ANNOUNCE] Apache Olingo 4.5.0 has been released

[Christian Amend]

Hello,

we proudly announce that Apache Olingo 4.5.0 has been released.
This is a stable Olingo release for OData Version 4
(see specification [1] and new features [2]).

This release is available for download:
http://olingo.apache.org/doc/odata4/download.html

Tutorials and documentation are also available:
http://olingo.apache.org/doc/odata4/index.html

Available also in central maven repository:
http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.olingo%22%20AND%20v%3A%224.5.0%22
and the Apache repository:
https://repository.apache.org/index.html#nexus-search;gav~org.apache.olingo~~4.5.0~~

If you would like to get involved please write to: u...@olingo.apache.org
Or subscribe to our mailing list as described here:
http://olingo.apache.org/support.html

Apache Olingo is a Java library which enables developers to
implement OData service providers (server) and consumers (clients)
for OData V2 and V4.

The Open Data Protocol (OData, http://www.odata.org/) is an open protocol
to allow the creation and consumption of queryable and interoperable
RESTful APIs in a simple and standard way.

[1]: http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html
[2]: 
http://docs.oasis-open.org/odata/new-in-odata/v4.0/cn01/new-in-odata-v4.0-cn01.html

Release Notes - Olingo - Version 4.5.0
---
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314520=12341547

Bug
[OLINGO-919] - $count is not supported as last segment on Functions/Actions
[OLINGO-1019] - Navigation Links not explicitly added to entity are
not shown in JSON "metadata=full" response
[OLINGO-1150] - Can't read Decimal value which value bigger than 10M
from MicrosoftCRM
[OLINGO-1166] - Annotations for members of Enum types in the CSDL
appear as siblings instead of as children
[OLINGO-1186] - OData 4 parsing older service metadata
[OLINGO-1194] - EntityResponse's location building doesn't check for
unicode strings
[OLINGO-1211] - netty-all is not a bundle but its dependency adds
extra import package to MANIFEST.MF in server-api module
[OLINGO-1230] - OpenType attribute is missing in meta serializer
[OLINGO-1237] - Serialization changes for odata.metadata=minimal
[OLINGO-1245] - Parsing issue with parens
[OLINGO-1252] - MetaDataParser will stack overflow when parsing circle
references recursively
[OLINGO-1276] - Client incorrectly parses stream with left brace in JSON string
New Feature
[OLINGO-1037] - V4: Support Geotypes on server in JSON
Improvement
[OLINGO-905] - Support $all in server-core-ext framework
[OLINGO-1152] - OLingo client crashes when encountering a null value
for an enum property
[OLINGO-1256] - Error code improvements
[OLINGO-1271] - Absolute Context URL with Service Dispatcher
Task
[OLINGO-1284] - V4: Build 4.5.0 release
Question
[OLINGO-1267] - Is it possible to generate deep insert response with
navigation properties?
[OLINGO-1268] - Olingo don't give error message like "The non-nullable
property is missing" for navigationProperty


Best Regards,
Christian

[jira] [Commented] (OLINGO-1284) V4: Build 4.5.0 release

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1284:
-

All tasks done except sending the release mail. I will do this once the 
distribution is available on all mirrors.

> V4: Build 4.5.0 release
> ---
>
> Key: OLINGO-1284
> URL: https://issues.apache.org/jira/browse/OLINGO-1284
> Project: Olingo
>  Issue Type: Task
>  Components: odata4-client, odata4-commons, odata4-ext, odata4-server
>Affects Versions: (Java) V4 4.4.0
>    Reporter: Christian Amend
>Assignee: Christian Amend
>Priority: Major
> Fix For: (Java) V4 4.5.0
>
>
> Build the 4.5.0 release
> Tasks:
> Release Candidate
> Upload to storage
> Start Voting
> Upload to Maven Central
> Upload to release store
> Update JavaDoc
> Send Release Mail to announce mailing list



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[VOTE] RC01 for 4.5.0 Olingo Release

[Christian Amend]

Hi,

This is a vote on the Apache Olingo 4.5.0 release. The vote will be
open at least for 72 hours (it will be closed on Thursday 09.08.2018)
and passes if no vote is (-1). If you feel that more time is needed to
close issues please vote with -1.

[ ] +1 Release this package as Apache Olingo 4.4.0
[ ] -1 Do not release this package because...

The release candidate is available here:
http://home.apache.org/~chrisam/olingo4/4.5.0-RC01/

The release candidate has been signed through the key 475D9522 in:
http://keyserver.kjsl.org:11371/pks/lookup?search=0x475D9522=vindex

The release candidate is based on the sources tagged with 4.5.0-RC01:
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=cde4f0723fa4825c09374dae50366b1bdf1d4143
and is based on the following commit id:
cde4f0723fa4825c09374dae50366b1bdf1d4143

The Olingo keys file can be found here:
https://dist.apache.org/repos/dist/release/olingo/KEYS

To perform a RAT check please use the following parameters:
mvn clean install -Pbuild.quality
This will assure that the RAT check is performed with the necessary excludes.

Release distribution files:
// compilable sources
Olingo-OData-4.5.0-RC01-source-release.zip
Olingo-OData-4.5.0-RC01-source-release.zip.asc
Olingo-OData-4.5.0-RC01-source-release.zip.md5
Olingo-OData-4.5.0-RC01-source-release.zip.sha512

// javadoc distribution
Olingo-OData-JavaDoc-4.5.0-RC01-javadoc.zip
Olingo-OData-JavaDoc-4.5.0-RC01-javadoc.zip.asc
Olingo-OData-JavaDoc-4.5.0-RC01-javadoc.zip.md5
Olingo-OData-JavaDoc-4.5.0-RC01-javadoc.zip.sha512

// odata client distribution for Android with dependencies
Olingo-OData-Client-for-Android-4.5.0-RC01-lib.zip
Olingo-OData-Client-for-Android-4.5.0-RC01-lib.zip.asc
Olingo-OData-Client-for-Android-4.5.0-RC01-lib.zip.md5
Olingo-OData-Client-for-Android-4.5.0-RC01-lib.zip.sha512

// odata client distribution for Java with dependencies
Olingo-OData-Client-for-Java-4.5.0-RC01-lib.zip
Olingo-OData-Client-for-Java-4.5.0-RC01-lib.zip.asc
Olingo-OData-Client-for-Java-4.5.0-RC01-lib.zip.md5
Olingo-OData-Client-for-Java-4.5.0-RC01-lib.zip.sha512

// odata server distribution for Java with dependencies
Olingo-OData-Server-for-Java-4.5.0-RC01-lib.zip
Olingo-OData-Server-for-Java-4.5.0-RC01-lib.zip.asc
Olingo-OData-Server-for-Java-4.5.0-RC01-lib.zip.md5
Olingo-OData-Server-for-Java-4.5.0-RC01-lib.zip.sha512

// odata server extension distribution for Java with dependencies
Olingo-OData-Server-Extension-for-Java-4.5.0-RC01-lib.zip
Olingo-OData-Server-Extension-for-Java-4.5.0-RC01-lib.zip.asc
Olingo-OData-Server-Extension-for-Java-4.5.0-RC01-lib.zip.md5
Olingo-OData-Server-Extension-for-Java-4.5.0-RC01-lib.zip.sha512

Here is my +1 (binding).

Best Regards,
Christian

[jira] [Created] (OLINGO-1284) V4: Build 4.5.0 release

[Christian Amend (JIRA)]

Christian Amend created OLINGO-1284:
---

 Summary: V4: Build 4.5.0 release
 Key: OLINGO-1284
 URL: https://issues.apache.org/jira/browse/OLINGO-1284
 Project: Olingo
  Issue Type: Task
  Components: odata4-client, odata4-commons, odata4-ext, odata4-server
Affects Versions: (Java) V4 4.4.0
Reporter: Christian Amend
Assignee: Christian Amend
 Fix For: (Java) V4 4.5.0


Build the 4.5.0 release

Tasks:
Release Candidate
Upload to storage
Start Voting
Upload to Maven Central
Upload to release store
Update JavaDoc
Send Release Mail to announce mailing list



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OLINGO-1227) NoSuchMethodError exception in EdmBinary

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1227:
-

Hi Daniel,

Apache Olingo requires the dependency Apache.commons.codec with version 1.6. 
This is specified in the POM. Can you please check if either:
1.  The dependency is not part of your classpath
2.  The dependency is not part of your war file
3.  There is another version of apache commons codec deployed? Maybe a 
lower version that does not have the required method.

Best Regards,
Christian


> NoSuchMethodError exception in EdmBinary
> 
>
> Key: OLINGO-1227
> URL: https://issues.apache.org/jira/browse/OLINGO-1227
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.10
>Reporter: Daniel Horvath
>Priority: Blocker
>
> Dear Colleagues,
> When we try to read an entity with binary property with Olingo we get the 
> following exception:
>  
> {code:java}
> Caused by: java.lang.NoSuchMethodError: 
> org.apache.commons.codec.binary.Base64.isBase64(Ljava/lang/String;)Z
> at 
> org.apache.olingo.odata2.core.edm.EdmBinary.validateLiteral(EdmBinary.java:60)
> at 
> org.apache.olingo.odata2.core.edm.EdmBinary.internalValueOfString(EdmBinary.java:91)
> at 
> org.apache.olingo.odata2.core.edm.AbstractSimpleType.valueOfString(AbstractSimpleType.java:91)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonPropertyConsumer.readSimpleProperty(JsonPropertyConsumer.java:236)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonPropertyConsumer.readPropertyValue(JsonPropertyConsumer.java:169)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntryConsumer.handleName(JsonEntryConsumer.java:172)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntryConsumer.readEntryContent(JsonEntryConsumer.java:130)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntryConsumer.readFeedEntry(JsonEntryConsumer.java:117)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonFeedConsumer.readArrayContent(JsonFeedConsumer.java:153)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonFeedConsumer.handleName(JsonFeedConsumer.java:122)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonFeedConsumer.readFeedContent(JsonFeedConsumer.java:111)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonFeedConsumer.readFeed(JsonFeedConsumer.java:96)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonFeedConsumer.readFeedStandalone(JsonFeedConsumer.java:63)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntityConsumer.readDeltaFeed(JsonEntityConsumer.java:95)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntityConsumer.readFeed(JsonEntityConsumer.java:81)
> at 
> org.apache.olingo.odata2.core.ep.JsonEntityProvider.readFeed(JsonEntityProvider.java:309)
> at 
> org.apache.olingo.odata2.core.ep.ProviderFacadeImpl.readFeed(ProviderFacadeImpl.java:166)
> at 
> org.apache.olingo.odata2.api.ep.EntityProvider.readFeed(EntityProvider.java:708)
> {code}
> Best regards,
> Daniel
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OLINGO-1222) Unable to create navigation links in Cars Project

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1222:
-

Hi Paul,

if I remember correclty this is a feature we did not implement for the sample. 
Are you using the JPA sample the Annotation sample or the plain library sample?

Best Regards,
Christian

> Unable to create navigation links in Cars Project
> -
>
> Key: OLINGO-1222
> URL: https://issues.apache.org/jira/browse/OLINGO-1222
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.10
> Environment: OSX & Windows
>Reporter: Paul
>Priority: Major
>
> When I create the Cars project from the default commands and use the generate 
> data function, the data is generated correctly and all the links such as from 
> a car to a driver work fine.
>  
> Opening postman, I then go and add a new car which also works fine. If I 
> attempt to add a driver to a car then I am getting an "Requested entity could 
> not be found".
>  
> I created a Car with id of 14
> URI:
> [http://localhost:8080/|http://localhost:8080/CarService.svc/Cars] 
> [MyFormula.svc|http://localhost:8080/MyFormula.svc/Cars('14')/$links/Driver] 
> [/Cars|http://localhost:8080/CarService.svc/Cars]
> Headers
> Content-Type: application/json
> Body:
> {
> "Id":"14",
> "Model":"Paul",
> "Price":"132",
> "ModelYear":2013
> }
>  
> I now want to link a driver to this car
> If I do a post
> URI:
> [http://localhost:8080/MyFormula.svc/Cars('14')/$links/Driver]
> Headers:
> Content-Type: application/json
> Body:
> {
>  "Id": "23",
>  "Name":"Jody",
>  "Lastname":"Schecter",
>  "Nickname":"SAMan"
> }
>  
> Then it does not work. and raises the error "Requested entity could not be 
> found".
>  
> If I try to manually link them via a put on the car this also fails.
>  
> I first create the driver above manually by posting to the Drivers collection.
> I do a PUT
> URI:
> http://localhost:8080/MyFormula.svc/Cars('14')/$links/Driver
> Headers:
> content-type: application/xml
> Body:
> ?xml version="1.0" encoding="utf-8" standalone="yes"?>
> http://schemas.microsoft.com/ado/2007/08/dataservices/metadata;>
> http://localhost:8080/MyFormula.svc/Drivers(23L)
> 
>  
> this also fails
>  
> Any ideas why this would not work? The links seem fine for those created by 
> the script in the source code but external creation does not allow links to 
> be set up



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OLINGO-1223) Remove final declaration from mulitple classes to make them extensible

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1223:
-

Hi Manuel,

a patch always helps especially if it includes tests :) We have a guide here on 
the contribution process: [http://olingo.apache.org/contribute.html]
Pull requests like in GitHub are unfortunately not possible because the Github 
<-> Apache Git Rpo integration is replication based. We can`t make changes to 
the GitHub repo and we can`t link pull requests.

As for your proposed changes: Sometimes the developer decided to make a class 
final to explicitly prevent extension. Especially core classes can change their 
implementation between versions and should not be extended. The goal would 
rather be to either register hooks that can be used or some other sort of 
mechanism that stays stable through releases.

WDYT?

Best Regards,
Christian

> Remove final declaration from mulitple classes to make them extensible
> --
>
> Key: OLINGO-1223
> URL: https://issues.apache.org/jira/browse/OLINGO-1223
> Project: Olingo
>  Issue Type: Wish
>  Components: odata2-jpa
>Affects Versions: V2 2.0.10
>Reporter: Manuel Blechschmidt
>Priority: Minor
>
> Hello,
> we are using Olingo a lot and it is an awesome library. The extensibility and 
> modularity is well designed.
> Unfortunately we needed some extensions for classes that are declared final.
>  * We added an localization feature that on the fly calls other functions 
> than getter or setters. we copied the following files and modified around 5% 
> of the source:
>  ** org.apache.olingo.odata2.jpa.processor.core.access.data.JPAEntityParser
>  ** org.apache.olingo.odata2.jpa.processor.core.ODataJPAResponseBuilderDefault
> Further there are other classes that I might want to extend:
>  * org.apache.olingo.odata2.jpa.processor.core.ODataEntityParser
>  * ...
> If it helps I can prepare a pull request where I remove all the final 
> declerations.
> /Manuel



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (OLINGO-1150) Can't read Decimal value which value bigger than 10M from MicrosoftCRM

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1150:
-

Hi,

I don`t see an issue with the code. Even if the specification does not allow 
scientific notation we have to deal with the behavior of the Jackson library. 
So I don`t mind.

Best Regards,

Christian

> Can't read Decimal value which value bigger than 10M from MicrosoftCRM
> --
>
> Key: OLINGO-1150
> URL: https://issues.apache.org/jira/browse/OLINGO-1150
> Project: Olingo
>  Issue Type: Bug
>Affects Versions: (Java) V4 4.3.0
>Reporter: Jin ZHAO
>Assignee: Ramesh Reddy
>Priority: Major
>  Labels: easyfix, unit-test
>
> {code:java}
> {
>   
> "@odata.context":"https://talend.api.crm.dynamics.com/api/data/v8.1/$metadata#salesorders(salesorderid,new_talend_test)","#Microsoft.Dynamics.CRM.FulfillSalesOrder":{
> 
> "title":"FulfillSalesOrder","target":"https://talend.api.crm.dynamics.com/api/data/v8.1/salesorders/Microsoft.Dynamics.CRM.FulfillSalesOrder;
>   },"#Microsoft.Dynamics.CRM.ValidateSharePointFolder":{
> 
> "title":"ValidateSharePointFolder","target":"https://talend.api.crm.dynamics.com/api/data/v8.1/salesorders/Microsoft.Dynamics.CRM.ValidateSharePointFolder;
>   },"value":[
> {
>   
> "@odata.type":"#Microsoft.Dynamics.CRM.salesorder","@odata.id":"https://talend.api.crm.dynamics.com/api/data/v8.1/salesorders(6a5ef029-1b66-e711-8114-e0071b6ad141)","@odata.etag":"W/\"7048734\"","@odata.editLink":"salesorders(6a5ef029-1b66-e711-8114-e0071b6ad141)","salesorde...@odata.type":"#Guid","salesorderid":"6a5ef029-1b66-e711-8114-e0071b6ad141","new_talend_t...@odata.type":"#Decimal","new_talend_test":31991163.,"_transactioncurrencyid_va...@odata.type":"#Guid","_transactioncurrencyid_value":"dca1714c-6d1a-e311-a5fb-b4b52f67b688","transactioncurrencyid@odata.associationLink":"https://talend.api.crm.dynamics.com/api/data/v8.1/salesorders(6a5ef029-1b66-e711-8114-e0071b6ad141)/transactioncurrencyid/$ref","transactioncurrencyid@odata.navigationLink":"https://talend.api.crm.dynamics.com/api/data/v8.1/salesorders(6a5ef029-1b66-e711-8114-e0071b6ad141)/transactioncurrencyid"
> }
>   ]
> }
> {code}
> We have this kind of response from Microsoft CRM which included this kind of 
> value:
> {code:java}
> "new_talend_t...@odata.type":"#Decimal","new_talend_test":31991163.
> {code}
> bellow is the error:
> {code:java}
> Exception in component tMicrosoftCrmInput_4 (TestCase_tMicrosoftCRMInput)
> java.lang.IllegalArgumentException: 
> org.apache.olingo.client.api.serialization.ODataDeserializerException: 
> java.io.IOException: 
> org.apache.olingo.commons.api.edm.EdmPrimitiveTypeException: The literal 
> '3.1991163E7' has illegal content.
>   at 
> org.apache.olingo.client.core.communication.request.retrieve.ODataEntitySetRequestImpl$ODataEntitySetResponseImpl.getBody(ODataEntitySetRequestImpl.java:87)
>   at 
> org.apache.olingo.client.core.communication.request.retrieve.ODataEntitySetRequestImpl$ODataEntitySetResponseImpl.getBody(ODataEntitySetRequestImpl.java:68)
>   at 
> local_project.testcase_tmicrosoftcrminput_0_1.TestCase_tMicrosoftCRMInput.tMicrosoftCrmInput_4Process(TestCase_tMicrosoftCRMInput.java:743)
>   at 
> local_project.testcase_tmicrosoftcrminput_0_1.TestCase_tMicrosoftCRMInput.runJobInTOS(TestCase_tMicrosoftCRMInput.java:1140)
>   at 
> local_project.testcase_tmicrosoftcrminput_0_1.TestCase_tMicrosoftCRMInput.main(TestCase_tMicrosoftCRMInput.java:989)
> Caused by: 
> org.apache.olingo.client.api.serialization.ODataDeserializerException: 
> java.io.IOException: 
> org.apache.olingo.commons.api.edm.EdmPrimitiveTypeException: The literal 
> '3.1991163E7' has illegal content.
>   at 
> org.apache.olingo.client.core.serialization.JsonDeserializer.toEntitySet(JsonDeserializer.java:402)
>   at 
> org.apache.olingo.client.core.serialization.ClientODataDeserializerImpl.toEntitySet(ClientODataDeserializerImpl.java:73)
>   at 
> org.apache.olingo.client.core.communication.request.retrieve.ODataEntitySetRequestImpl$ODataEntitySetResponseImpl.getBody(ODataEntitySetRequestIm

[jira] [Resolved] (OLINGO-1210) OData V2.0: 2.0.10 Release

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1210.
-
Resolution: Fixed

> OData V2.0: 2.0.10 Release
> --
>
> Key: OLINGO-1210
> URL: https://issues.apache.org/jira/browse/OLINGO-1210
> Project: Olingo
>  Issue Type: Task
>  Components: odata2-annotation, odata2-core, odata2-documentation, 
> odata2-jpa
>Affects Versions: V2 2.0.10
>Reporter: Christian Amend
>    Assignee: Christian Amend
> Fix For: V2 2.0.10
>
>
> Provide a new 2.0.10 release:
> Release candidate
> Voting
> Release
> Update Distribution
> Update Website



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (OLINGO-1220) Bad request (error 400) for entries with slash or backslash character in string literal of key predicate

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1220.
-
Resolution: Information Provided
  Assignee: Christian Amend

Hi Michele,

the Olingo library does not block this. This is usually done by the runtime 
environment e.g. Apache Tomcat as a security measure. You can check this by 
looking at the response body. If you see an empty response body the request 
does not even reach the Olingo servlet. If you get back an OData Error Document 
then there is a bug in the library. In this case we would need a stacktrace tif 
possible to troubleshoot the issue.

Here is a stackoverflow answer for Apache Tomcat: 
https://stackoverflow.com/questions/9719224/coding-forward-and-backward-slashes-in-tomcat-7

Best Regards,
Christian

> Bad request (error 400) for entries with slash or backslash character in 
> string literal of key predicate
> 
>
> Key: OLINGO-1220
> URL: https://issues.apache.org/jira/browse/OLINGO-1220
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.9, V2 2.0.10
>Reporter: M Carissimi
>    Assignee: Christian Amend
>Priority: Critical
>
> Hello,
> our OData service implemented with Olingo 2.0.x refuses to accept requests 
> for entries where the string literal of a key predicate contains the slash 
> (/) or backslash (\) characters. In both cases encoding the slash or 
> backslash character with the corresponding code (%2F and %5C respectively) 
> does not resolve the issue. In all cases an error 400 is returned by Olingo
> These are some example of failing URLs:
> https:///odata/WELL('Alice-09-d%2Fe')
> https:///odata/WELL('Alice-12-k%5Cm')
> Can you please investigate this issue and let me know if there's anything we 
> can do in our code to prevent it from happening?
> Regards
> Michele



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[ANNOUNCE] Apache Olingo 2.0.10 has been released

[Christian Amend]

Hello,

Apache Olingo 2.0.10 has been released.

This is a patch release of Apache Olingo which includes Bugfixes and
Improvements for client and server use cases.

This release is available for download:
http://olingo.apache.org/download.html

Apache Olingo is a Java library which enables developers to implement OData
producers and OData consumers.

The Open Data Protocol (OData, http://odata.org) is a Web protocol for
querying and updating data that provides a way to unlock your data and free
it from silos that exist in applications today. OData does this by applying
and building upon Web technologies such as HTTP, Atom Publishing Protocol
(AtomPub) and JSON to provide access to information from a variety of
applications, services, and stores.

Best Regards, Michael

Release Notes - Olingo - Version 2.0.10
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314520=12341072

Bug
[OLINGO-996] - ODataJPA Extension creates illegal Entity Container Name
[OLINGO-1108] - Edm.Decimal not supported in OData Create requests (POST)
[OLINGO-1146] - CLONE - Cannot Filter on Navigation Property
Improvement
[OLINGO-1192] - Parameterizing JPA Queries
New Feature
[OLINGO-605] - Olingo should support custom types e.g. Geometry by using
XmlAdapter from JaxB

[jira] [Commented] (OLINGO-1146) CLONE - Cannot Filter on Navigation Property

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1146:
-

Hi Michael,

this is already part of the current master: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=6ce2421a5d7ebb40d6456d12f38913f725e87457

The 2.0.10 release is currently in progress. It should be available by the end 
of the week.

Best Regards,
Christian

> CLONE - Cannot Filter on Navigation Property
> 
>
> Key: OLINGO-1146
> URL: https://issues.apache.org/jira/browse/OLINGO-1146
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-jpa
>Affects Versions: V2 2.0.0
>Reporter: igor nemtsov
>Assignee: Michael Bolz
> Fix For: V2 2.0.10
>
> Attachments: olingo-414-exception.diff, olingo-414-patch.diff, 
> olingo-odata2-parent.patch
>
>
> We are receiving an error when we try to filter on a navigation property.  In 
> our solution we have a Notification entity and a User entity, we would like 
> to retrieve a specific Notification but only if it is linked to the 
> requesting user.  This would involve an ODATA request which filters on both 
> the UserId and the NotificationId.  An example of the URL we are invoking is:
> dspplatform.svc/Notifications?$filter=NotificationId%20eq%204%20and%20UserDetails/UserId%20eq%202
> This returns the following error:
> org.apache.olingo.odata2.core.edm.provider.EdmNavigationPropertyImplProv 
> cannot be cast to org.apache.olingo.odata2.api.edm.EdmProperty
> Can you please advise on how to perform filters on a Navigation property as 
> we need this as part of our core functionality?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (OLINGO-1210) OData V2.0: 2.0.10 Release

[Christian Amend (JIRA)]

Christian Amend created OLINGO-1210:
---

 Summary: OData V2.0: 2.0.10 Release
 Key: OLINGO-1210
 URL: https://issues.apache.org/jira/browse/OLINGO-1210
 Project: Olingo
  Issue Type: Task
  Components: odata2-annotation, odata2-core, odata2-documentation, 
odata2-jpa
Affects Versions: V2 2.0.10
Reporter: Christian Amend
Assignee: Christian Amend
 Fix For: V2 2.0.10


Provide a new 2.0.10 release:

Release candidate
Voting
Release
Update Distribution
Update Website




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (OLINGO-1179) Copying oDataHeaders from parent call to subsequent calls

[Christian Amend (JIRA)]

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

Christian Amend updated OLINGO-1179:

Description: tbd  (was: The issue was found out in the below message.
https://support.wdf.sap.corp/sap/support/message/1770348956)

> Copying oDataHeaders from parent call to subsequent calls
> -
>
> Key: OLINGO-1179
> URL: https://issues.apache.org/jira/browse/OLINGO-1179
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-client
>Affects Versions: (Java) V4 4.3.0, (Java) V4 4.4.0
>Reporter: Sowmya
> Attachments: FixForIncident1770348956.patch
>
>
> tbd



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (OLINGO-1108) Edm.Decimal not supported in OData Create requests (POST)

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1108.
-
   Resolution: Not A Bug
 Assignee: Christian Amend
Fix Version/s: V2 2.0.10

EDM.Decimal values must be Strings in a payload and not JSON Numbers according 
to the specification. So your client needs to be adjusted.

See: http://www.odata.org/documentation/odata-version-2-0/json-format/ 
Edm.Decimal Literal form of Edm.Decimal as used in URIs formatted as a JSON 
string

> Edm.Decimal not supported in OData Create requests (POST)
> -
>
> Key: OLINGO-1108
> URL: https://issues.apache.org/jira/browse/OLINGO-1108
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.8
>Reporter: Patrick Haller
>Assignee: Christian Amend
> Fix For: V2 2.0.10
>
>
> We've got Edm.Decimal on a POST request (OData Create). 
> Upon sending the request, we see the following exception in the server log.
> In JsonPropertyConsumer.readSimpleProperty()'s switch case, we have
> type=Edm.Decimal
> tokenType=JsonToken.NUMBER
> and therefore end up with throwing INVALID_PROPERTY_VALUE.
> *exception*
> {quote}Caused by: org.apache.olingo.odata2.api.ep.EntityProviderException: 
> Provided value for the property 'Quantity' is not compatible with the 
> property.
>   at 
> org.apache.olingo.odata2.core.ep.consumer.JsonPropertyConsumer.readSimpleProperty(JsonPropertyConsumer.java:227)
>   at 
> org.apache.olingo.odata2.core.ep.consumer.JsonPropertyConsumer.readPropertyValue(JsonPropertyConsumer.java:169)
>   at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntryConsumer.handleName(JsonEntryConsumer.java:172)
>   at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntryConsumer.readEntryContent(JsonEntryConsumer.java:130)
>   at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntryConsumer.readSingleEntry(JsonEntryConsumer.java:93)
>   at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntityConsumer.readEntry(JsonEntityConsumer.java:57)
>   at 
> org.apache.olingo.odata2.core.ep.JsonEntityProvider.readEntry(JsonEntityProvider.java:315)
>   at 
> org.apache.olingo.odata2.core.ep.ProviderFacadeImpl.readEntry(ProviderFacadeImpl.java:179)
>   at 
> org.apache.olingo.odata2.api.ep.EntityProvider.readEntry(EntityProvider.java:746)
>   at 
> org.apache.olingo.odata2.jpa.processor.core.ODataEntityParser.parseEntry(ODataEntityParser.java:64)
>   ... 66 common frames omitted{quote}
> *Data Model classes*
> *Java Client (Spring RestTemplate)*
> {quote}class MyPostRequest {
> @JsonProperty("Cost")
> BigDecimal cost;
> }{quote}
> *Java Server (Olingo)*
> {quote}class ProjectCost implements Serializable
> {
> // ...
> @Column
> private BigDecimal cost;
> }{quote}
> *$metadata*
> {quote}http://schemas.microsoft.com/ado/2007/06/edmx; 
> Version="1.0">
>  xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata; 
> m:DataServiceVersion="1.0">
> http://schemas.microsoft.com/ado/2008/09/edm; 
> Namespace="project">
> http://www.sap.com/Protocols/SAPData; Name="Project" 
> sap:label="Project">
> 
> 
> 
> http://www.sap.com/Protocols/SAPData; Name="LastUpdate" 
> Type="Edm.DateTime" Nullable="true" sap:label="Last Update"/>
> http://www.sap.com/Protocols/SAPData; Name="Name" 
> Type="Edm.String" Nullable="true" MaxLength="255" sap:label="Project"/>
> http://www.sap.com/Protocols/SAPData; Name="ProjectType" 
> Type="Edm.String" Nullable="true" MaxLength="255" sap:label="Type"/>
> http://www.sap.com/Protocols/SAPData; Name="Responsible" 
> Type="Edm.String" Nullable="true" MaxLength="255" sap:label="Person 
> Responsible"/>
> http://www.sap.com/Protocols/SAPData; Name="Stage" 
> Type="Edm.String" Nullable="true" MaxLength="255" sap:label="Stage"/>
> http://www.sap.com/Protocols/SAPData; Name="Status" 
> Type="Edm.String" Nullable="true" MaxLength="255" sap:label="Status"/>
> 
>  Relationship="project.Project_ProjectCost_One_Many0" FromRole="Project" 
> ToRole="ProjectCost"/>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  MaxLength="255"/>
> 
> 
> 
>  MaxLength="255"/>
>  Nullable="true" MaxLength="255"/>
>  MaxLength="255"/>
> 
>  Relationship="project.Project_ProjectCost_One_Many0" FromRole="ProjectCost" 
> ToRole="Project"/>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  Association="project.Project_ProjectCost_One_Many0">
> 
> 
> 
> 
> 
> 
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (OLINGO-1166) Annotations for members of Enum types in the CSDL appear as siblings instead of as children

[Christian Amend (JIRA)]

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

Christian Amend reassigned OLINGO-1166:
---

Assignee: Christian Amend

> Annotations for members of Enum types in the CSDL appear as siblings instead 
> of as children 
> 
>
> Key: OLINGO-1166
> URL: https://issues.apache.org/jira/browse/OLINGO-1166
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-server
>Affects Versions: (Java) V4 4.3.0
>Reporter: Tom van Wietmarschen
>    Assignee: Christian Amend
>  Labels: easyfix
> Fix For: (Java) V4 4.5.0
>
> Attachments: 0001-OLINGO-1166-Add-test-case.patch, 
> 0001-OLINGO-1166-Fix-serialization-of-annotations-for-enu.patch
>
>
> When adding annotations to members of an enum type, the annotations appear as 
> siblings of the member element, while they should appear as children (OData 
> v4.0, part 3: CSDL, section 14.3)
> This is caused by a bug in 
> {{org.apache.olingo.server.core.serializer.xml.MetadataDocumentXmlSerializer}}.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (OLINGO-1166) Annotations for members of Enum types in the CSDL appear as siblings instead of as children

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1166.
-
   Resolution: Fixed
Fix Version/s: (Java) V4 4.5.0

Hi Tom,
I applied the changes to the master branch. Thanks for providing the tests and 
sorry for missing them when I built the release.
Best Regards,
Christian

> Annotations for members of Enum types in the CSDL appear as siblings instead 
> of as children 
> 
>
> Key: OLINGO-1166
> URL: https://issues.apache.org/jira/browse/OLINGO-1166
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-server
>Affects Versions: (Java) V4 4.3.0
>Reporter: Tom van Wietmarschen
>  Labels: easyfix
> Fix For: (Java) V4 4.5.0
>
> Attachments: 0001-OLINGO-1166-Add-test-case.patch, 
> 0001-OLINGO-1166-Fix-serialization-of-annotations-for-enu.patch
>
>
> When adding annotations to members of an enum type, the annotations appear as 
> siblings of the member element, while they should appear as children (OData 
> v4.0, part 3: CSDL, section 14.3)
> This is caused by a bug in 
> {{org.apache.olingo.server.core.serializer.xml.MetadataDocumentXmlSerializer}}.
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (OLINGO-1152) OLingo client crashes when encountering a null value for an enum property

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1152.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: (Java) V4 4.5.0

Hi Tom,

I applied the changes to the master branch. Thanks for providing the tests and 
sorry for missing them when I built the release.

Best Regards,
Christian

> OLingo client crashes when encountering a null value for an enum property
> -
>
> Key: OLINGO-1152
> URL: https://issues.apache.org/jira/browse/OLINGO-1152
> Project: Olingo
>  Issue Type: Improvement
>  Components: odata4-client
>Affects Versions: (Java) V4 4.3.0
>Reporter: Tom van Wietmarschen
>Assignee: Christian Amend
> Fix For: (Java) V4 4.5.0
>
> Attachments: 
> 0001-OLINGO-1152-Fix-IllegalArgumentException-when-enum-p.patch, 
> 0001-OLINGO-1152-Test-case.patch
>
>
> An IllegalArgumentException is thrown when the OLingo client encounters a 
> enum property that has a null value. It turns out the Property's value is set 
> to "null" (a String) instead of null. Tracing back the source of the 
> null-String shows 
> {{org.apache.olingo.client.core.serialization.JsonDeserializer}} always 
> assumes Enum values are Strings. (It calls node.asText() even on a NullNode), 
> adding a isNull() check solves the issue. Patch to follow. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (OLINGO-1171) V4: Build 4.4.0 release

[Christian Amend (JIRA)]

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

Christian Amend closed OLINGO-1171.
---
Resolution: Fixed

> V4: Build 4.4.0 release
> ---
>
> Key: OLINGO-1171
> URL: https://issues.apache.org/jira/browse/OLINGO-1171
> Project: Olingo
>  Issue Type: Task
>  Components: odata4-client, odata4-commons, odata4-samples, 
> odata4-server
>Affects Versions: (Java) V4 4.3.0
>Reporter: Christian Amend
>    Assignee: Christian Amend
> Fix For: (Java) V4 4.4.0
>
>
> Build the 4.4.0 release
> Tasks:
> Release Candidate
> Upload to storage
> Start Voting
> Upload to Maven Central
> Upload to release store
> Update JavaDoc
> Send Release Mail to announce mailing list



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[ANNOUNCE] Apache Olingo 4.4.0 has been released

[Christian Amend]

Hello,

we announce that Apache Olingo 4.4.0 has been released.

This is the second stable Olingo release version for OData Version 4
(see specification [1] and new features [2]).

This release is available for download:
http://olingo.apache.org/doc/odata4/download.html
New Tutorials and documentation are also available:
http://olingo.apache.org/doc/odata4/index.html
Available also in central maven repository:
http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.olingo%22%20AND%20v%3A%224.4.0%22

If you would like to get involved please write to: 
Or subscribe to our mailing list: http://olingo.apache.org/support.html

Apache Olingo is a Java library which enables developers to
implement OData service providers (server) and consumers (clients).

The Open Data Protocol (OData, http://www.odata.org/) is an open protocol
to allow the creation and consumption of queryable and interoperable
RESTful APIs in a simple and standard way.


[1]: http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html
[2]: 
http://docs.oasis-open.org/odata/new-in-odata/v4.0/cn01/new-in-odata-v4.0-cn01.html

Release Notes - Olingo - Version 4.4.0
---
Link: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314520=12338257

Bug
[OLINGO-753] - URIUtils.buildFunctionInvokeURI() build a wrong uri
when the uri parameter contains /$count
[OLINGO-917] - $entity request with $select system option always fails to parse
[OLINGO-975] - Olingo client sends incorrect types for collection members
[OLINGO-1008] - Metadata Parser is unable to parse external references
of Microsoft dynamics CRM Odata metadata
[OLINGO-1033] - V4: @odata.type annotation incorrect for primitive types
[OLINGO-1046] - Whitespaces in functions not allowed
[OLINGO-1058] - OData V4.0: NextLink Support in streaming to enable
server side pagination
[OLINGO-1064] - ComplexType is deserialized as Primitive Type if the
value is NULL
[OLINGO-1073] - Collections with derived complex types - wrong odata.type
[OLINGO-1076] - Validating Query Options for correct syntax
[OLINGO-1080] - Support Entity Iterator in batch
[OLINGO-1083] - OData V4 Singleton has EntityType instead of Type
attribute in XML metadata
[OLINGO-1102] - ODataErrorResponseChecker.checkResponse(...) not
return detail error message for ODataServerErrorException
[OLINGO-1104] - NavigationLink missing from JSON with expand and metadata=full
[OLINGO-1107] - UriDecoder should use java.net.URLDecoder
[OLINGO-] - EntityResponse's location building not taking
property's facets in to consideration
[OLINGO-1112] - Compound Key not handled correctly EntityResponse
[OLINGO-1132] - Type information is lost when primitive properties
with null value is updated
Improvement
[OLINGO-846] - Flexible URL parsing for System Query Options
[OLINGO-1028] - V4: $filter statements on navigation properties
[OLINGO-1099] - Refactor the V4 $levels implementation
New Feature
[OLINGO-1059] - OData V4.0: Cross Service EDM
[OLINGO-1077] - OData V4.0: EntityIterator count support
Task
[OLINGO-1171] - V4: Build 4.4.0 release
Test
[OLINGO-1106] - Custom Query options in batch request

Best Regards,
Christian

[jira] [Updated] (OLINGO-905) Support $all in server-core-ext framework

[Christian Amend (JIRA)]

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

Christian Amend updated OLINGO-905:
---
Fix Version/s: (was: (Java) V4 4.4.0)
   (Java) V4 4.5.0

> Support $all in server-core-ext framework
> -
>
> Key: OLINGO-905
> URL: https://issues.apache.org/jira/browse/OLINGO-905
> Project: Olingo
>  Issue Type: Improvement
>  Components: odata4-server
>Affects Versions: (Java) V4 4.1.0
>Reporter: Ramesh Reddy
>Assignee: Ramesh Reddy
> Fix For: (Java) V4 4.5.0
>
>
> server-core-ext currently does not support $all option, at a minimum the 
> service should return a 501 not-implemented message.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (OLINGO-1019) Navigation Links not explicitly added to entity are not shown in JSON "metadata=full" response

[Christian Amend (JIRA)]

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

Christian Amend updated OLINGO-1019:

Fix Version/s: (was: (Java) V4 4.4.0)
   (Java) V4 4.5.0

> Navigation Links not explicitly added to entity are not shown in JSON 
> "metadata=full" response
> --
>
> Key: OLINGO-1019
> URL: https://issues.apache.org/jira/browse/OLINGO-1019
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-server
>Affects Versions: (Java) V4 4.2.0
>Reporter: Ashan Bakmeedeniya
>Assignee: Ramesh Reddy
> Fix For: (Java) V4 4.5.0
>
> Attachments: OLINGO-1019.patch
>
>
> Navigation links not added to entity explicitly are not serialized in the 
> json response when client request "odata.metadata=full".
> In ODataXmlSerializer even if navigation links are not explicitly added to 
> the entity, they are serialized to response. Hence, one would expect similar 
> behavior with  ODataJsonSerializer as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (OLINGO-1171) V4: Build 4.4.0 release

[Christian Amend (JIRA)]

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

Christian Amend updated OLINGO-1171:

Fix Version/s: (was: (Java) V4 4.4.0)
   (Java) V4 4.5.0

> V4: Build 4.4.0 release
> ---
>
> Key: OLINGO-1171
> URL: https://issues.apache.org/jira/browse/OLINGO-1171
> Project: Olingo
>  Issue Type: Task
>  Components: odata4-client, odata4-commons, odata4-samples, 
> odata4-server
>Affects Versions: (Java) V4 4.3.0
>Reporter: Christian Amend
>    Assignee: Christian Amend
> Fix For: (Java) V4 4.5.0
>
>
> Build the 4.4.0 release
> Tasks:
> Release Candidate
> Upload to storage
> Start Voting
> Upload to Maven Central
> Upload to release store
> Update JavaDoc
> Send Release Mail to announce mailing list



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (OLINGO-919) $count is not supported as last segment on Functions/Actions

[Christian Amend (JIRA)]

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

Christian Amend updated OLINGO-919:
---
Fix Version/s: (was: (Java) V4 4.4.0)
   (Java) V4 4.5.0

> $count is not supported as last segment on Functions/Actions
> 
>
> Key: OLINGO-919
> URL: https://issues.apache.org/jira/browse/OLINGO-919
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-server
>Affects Versions: (Java) V4 4.1.0
>Reporter: Ramesh Reddy
>Assignee: Christian Amend
> Fix For: (Java) V4 4.5.0
>
>
> See more details on OLINGO-915
> When function (including function imports) and action (and AI ) return 
> collection values, then that url can end with $count. For reference see [1]
> [1] 
> http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part2-url-conventions/odata-v4.0-errata02-os-part2-url-conventions-complete.html#_Toc406398093



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (OLINGO-1171) V4: Build 4.4.0 release

[Christian Amend (JIRA)]

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

Christian Amend updated OLINGO-1171:

Description: 
Build the 4.4.0 release

Tasks:
Release Candidate
Upload to storage
Start Voting
Upload to Maven Central
Upload to release store
Update JavaDoc
Send Release Mail to announce mailing list

  was:
Build the 4.4.0 release

Tasks:
Release Candidate
Upload to storage
Start Voting
Upload to release store
Update JavaDoc
Send Release Mail to announce mailing list


> V4: Build 4.4.0 release
> ---
>
> Key: OLINGO-1171
> URL: https://issues.apache.org/jira/browse/OLINGO-1171
> Project: Olingo
>  Issue Type: Task
>  Components: odata4-client, odata4-commons, odata4-samples, 
> odata4-server
>Affects Versions: (Java) V4 4.3.0
>Reporter: Christian Amend
>    Assignee: Christian Amend
> Fix For: (Java) V4 4.4.0
>
>
> Build the 4.4.0 release
> Tasks:
> Release Candidate
> Upload to storage
> Start Voting
> Upload to Maven Central
> Upload to release store
> Update JavaDoc
> Send Release Mail to announce mailing list



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (OLINGO-1121) Can not create entities via to one navigation property

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1121.
-
Resolution: Won't Fix
  Assignee: Christian Amend

The V2 specification does not allow POST requests on navigation to one. POST 
methods are only allowed for collections:

As specified in [RFC5023] section 9.2, insert requests use the HTTP POST method 
and the request
URI must represent an AtomPub Collection. Because a collection maps to a 
conceptual schema
definition language (CSDL) in an Entity Data Model, the HTTP request line URI 
MUST be any valid
data service URI, as defined in URI Format: Resource Addressing Rules (section 
2.2.3), which
identifies a collection of entities.

> Can not create entities via to one navigation property
> --
>
> Key: OLINGO-1121
> URL: https://issues.apache.org/jira/browse/OLINGO-1121
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.8
>Reporter: Oliver Grande
>Assignee: Christian Amend
>
> I try to create three entities via a $batch request with three POSTs. One 
> "top-level" entity and two related ones. One of the navigation properties is 
> a "To One" and the other one is a "To Many" relation.
> Whereas the "Top Level" and the "To Many" are processed without any problem, 
> the To One aborts with an  ODataMethodNotAllowedException. 
> Some debugging showed that the "To Many" gets UriType URI6B, where as "To 
> One" gets UriType URI6A. Later in ODataRequestHandler. validateUriMethod POST 
> is forbidden for URI6A.
> Please enable POST for URI6A  as well.
> Regards,
> Oliver



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (OLINGO-736) JPAEntity does not update null values

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-736:


[~petrescs] Thanks a lot for the patch. The fix will work with String values 
but for other primitive types it will fail. Would you consider contributing a 
patch that takes other types like bolean and numeric values into account as 
well?

> JPAEntity does not update null values
> -
>
> Key: OLINGO-736
> URL: https://issues.apache.org/jira/browse/OLINGO-736
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-jpa
>Affects Versions: V2 2.0.4
> Environment: Windows 7 64bit, Google Chrome 43.0.2357.134, JDK 
> 1.8.0_51
>Reporter: Reinhard Fuchs
>Assignee: Chandan V.A
>Priority: Minor
> Attachments: OLINGO_736.patch
>
>
> In "JPAEntity.setProperty" there is an condition regarding null values ("if 
> (entityPropertyValue != null) ". This condition prevents database simple type 
> values being updateted with null value. According the OData Specification in 
> Point 3.3 (http://www.odata.org/documentation/odata-version-2-0/operations/) 
> this should work.
> Please complete this condition with an else:
> else {
>   method.invoke(entity, entityPropertyValue);
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (OLINGO-1046) Whitespaces in functions not allowed

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1046:
-

[~rareddy] the patch looks good. Very neat and should releax the parsing just 
fine. +1 for merging and thanks a lot for taking care of this :)

> Whitespaces in functions not allowed
> 
>
> Key: OLINGO-1046
> URL: https://issues.apache.org/jira/browse/OLINGO-1046
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-server
>Affects Versions: (Java) V4 4.3.0
>Reporter: Frederik Zimmer
>Assignee: Ramesh Reddy
>
> Whitespaces before/after comma/parenthesis in functions are allowed by the 
> ABNF but Olingo is unable to parse them.
> This would result in an error (inserted space after comma in Testcase of 
> TestFullResourcePath):
> startswith(PropertyCompAllPrim/PropertyString, 'Wall')
> ABNF example:
> startsWithMethodCallExpr = 'startswith' OPEN BWS commonExpr BWS COMMA BWS 
> commonExpr BWS CLOSE
> BWS =  *( SP / HTAB / "%20" / "%09" )  ; "bad" whitespace



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (OLINGO-1046) Whitespaces in functions not allowed

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1046:
-

Hi Ramesh sorry I missed this patch. Will take a look at it.


> Whitespaces in functions not allowed
> 
>
> Key: OLINGO-1046
> URL: https://issues.apache.org/jira/browse/OLINGO-1046
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-server
>Affects Versions: (Java) V4 4.3.0
>Reporter: Frederik Zimmer
>Assignee: Ramesh Reddy
>
> Whitespaces before/after comma/parenthesis in functions are allowed by the 
> ABNF but Olingo is unable to parse them.
> This would result in an error (inserted space after comma in Testcase of 
> TestFullResourcePath):
> startswith(PropertyCompAllPrim/PropertyString, 'Wall')
> ABNF example:
> startsWithMethodCallExpr = 'startswith' OPEN BWS commonExpr BWS COMMA BWS 
> commonExpr BWS CLOSE
> BWS =  *( SP / HTAB / "%20" / "%09" )  ; "bad" whitespace



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-753) URIUtils.buildFunctionInvokeURI() build a wrong uri when the uri parameter contains /$count

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-753.

   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: (Java) V4 4.4.0

Thanks for the contribution. I applied it with the following commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=74a2da7d5eefd99d10a4d21fe076c2fa33e1e4a4

> URIUtils.buildFunctionInvokeURI() build a wrong uri when the uri parameter 
> contains /$count
> ---
>
> Key: OLINGO-753
> URL: https://issues.apache.org/jira/browse/OLINGO-753
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-client
>Affects Versions: (Java) V4 4.0.0-beta-03
>Reporter: Riccardo Mariani
>    Assignee: Christian Amend
> Fix For: (Java) V4 4.4.0
>
> Attachments: OLINGO-753.diff
>
>
> The /$count option is not concatenated properly after function parameters



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1102) ODataErrorResponseChecker.checkResponse(...) not return detail error message for ODataServerErrorException

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1102.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: (Java) V4 4.4.0

Thanks for the contribution. I applied the patch with th efollowing commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=a16a16841b03fe27b1fb0dab20a0d0029a6de335

> ODataErrorResponseChecker.checkResponse(...) not return detail error message 
> for ODataServerErrorException 
> ---
>
> Key: OLINGO-1102
> URL: https://issues.apache.org/jira/browse/OLINGO-1102
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-client
>Affects Versions: (Java) V4 4.3.0
>Reporter: Jin ZHAO
>    Assignee: Christian Amend
> Fix For: (Java) V4 4.4.0
>
> Attachments: 500-internal-server-error.png, ErrorMessage.diff
>
>
> When I access Microsot CRM online with Olingo client code, My request 
> https://talend.api.crm.dynamics.com/api/data/v8.1/subscriptionsyncentriesoutlook
>  response return: *Status:500 Internal Server Error* with detail error 
> message(see attached screenshot: 500-internal-server-error.png)
> but 
> [ODataErrorResponseChecker.java#L73|https://github.com/apache/olingo-odata4/blob/8515b48dd5e09e4597d0b396326bd6a074efa1f5/lib/client-core/src/main/java/org/apache/olingo/client/core/communication/header/ODataErrorResponseChecker.java#L73]
>  not included the detail message in ODataServerErrorException
> This would very hard know why get 500 error.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1099) Refactor the V4 $levels implementation

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1099.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: (Java) V4 4.4.0

Thanks for the contribution. I applied the patch with the following commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=f55205561ea5a4f7d37b2015e5f06bfdbb704c89

> Refactor the V4 $levels implementation
> --
>
> Key: OLINGO-1099
> URL: https://issues.apache.org/jira/browse/OLINGO-1099
> Project: Olingo
>  Issue Type: Improvement
>  Components: odata4-server
>Affects Versions: (Java) V4 4.1.0
>Reporter: Archana Rai
>Assignee: Christian Amend
>Priority: Minor
> Fix For: (Java) V4 4.4.0
>
> Attachments: f7aa6aac.diff
>
>
> Refactor the V4 $levels implementation based on the code review notes:
> There have been ExpandSelectHelper changes. If they are not needed revert 
> them.
> With version 4.3.0 EntityIds  became mandatory in the ODataEntity object. 
> Revert this change.
> -> If not there generate the key
> -> if not possible to generate because key fields are missing or the id field 
> isn`t set but the Id is mandatory then throw an exception
> $levels specific:
> Do not check for ancestors based on the ODataEntity ID. Just use object 
> references and comape with ==
> $levels=1 expandes Navigation properties for the first level. $levels=1 has 
> the same functionality as leaving it away.
> ExpandSelectHelper getExpandAll and isExpandAll have the same functionallity. 
> Remove on method.
> Important:
> Only navigation properties of the same type get expanded. Not all of them. 
> This is a bug.
> Refactor navigation property serialization. There should only be one call to 
> writeExpandedNavigation property! Not multiple ones based on some flags etc.
> Check for cycle only if navigation property has to be expanded.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-975) Olingo client sends incorrect types for collection members

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-975.

   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: (Java) V4 4.4.0

Thanks for the contribution. I have applied the patch with the following 
commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=173f0d78ad0b5388ee75d744e91e7694b9da9671

> Olingo client sends incorrect types for collection members
> --
>
> Key: OLINGO-975
> URL: https://issues.apache.org/jira/browse/OLINGO-975
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-client
>Affects Versions: (Java) V4 4.1.0
>Reporter: Torsten Küpper
>Assignee: Christian Amend
> Fix For: (Java) V4 4.4.0
>
> Attachments: OLINGO975.diff
>
>
> Hi, 
> having derived class types in a collection, the Olingo Java client
> sends only the collection type. E.g. given that Employee and Customer both 
> inherit from Person, and we have a collection RelatedPersons of Person, if 
> the first collection member is an instance of Employee and the second a 
> Customer, then the request contains
>   "relatedpers...@odata.type": "#Collection(Person)",
>   "RelatedPersons": [{
>  "@odata.type": "Person", ...
>  },
>  {
>  "@odata.type": "Person", ...
>  }
>  ]
> but correct would be
>   "relatedpers...@odata.type": "#Collection(Person)",
>   "RelatedPersons": [{
>  "@odata.type": "Employee", ...
>  },
>  {
>  "@odata.type": "Customer", ...
>  }
>  ]
> I found OLINGO-825 which seems to describe the issue just on the server
> side, which then received a fix.
> It seems to me the cause is that type gets lost in ODataBinderImpl when a 
> translation of data to some internal representation which has no type 
> information, at least for collection members, is done.
> In the reverse direction, when Olingo client receives a response, the type 
> info is thrown away in JsonDeserializer in fromCollection
> if (child.has(Constants.JSON_TYPE)) {
>   ((ObjectNode) child).remove(Constants.JSON_TYPE);
> }
> What could be done to fix this?
> Would a change be accepted which adds the type information to each
> collection member in the internal representation?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1064) ComplexType is deserialized as Primitive Type if the value is NULL

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1064.
-
   Resolution: Fixed
Fix Version/s: (Java) V4 4.4.0

Thanks for the contribution. I applied the patch with the following commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=272719d59fe84e7010b7c2117c1db0c31bfc0e00


> ComplexType is deserialized as Primitive Type if the value is NULL
> --
>
> Key: OLINGO-1064
> URL: https://issues.apache.org/jira/browse/OLINGO-1064
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-client, odata4-commons
>Affects Versions: (Java) V4 4.2.0
>Reporter: Punith DG
>Assignee: Christian Amend
> Fix For: (Java) V4 4.4.0
>
> Attachments: complexType.png, OLINGO-1064.diff
>
>
> The ODataClient deserializer wrongly converts the Complex Type field to 
> Primitive Type field if the value received for the complex type is NULL.
> e.g. on querying Person data from OData TripPin service 
> (https://services.odata.org/TripPinRESTierService) I received below JSON 
> response.
> {
>   "@odata.context": 
> "http://services.odata.org/TripPinRESTierService/(S(myhztseklikbg41mbg03ugk5))/$metadata#People(AddressInfo,FavoriteFeature,FirstName,HomeAddress,LastName,UserName)",
>   "value": [{
>   "FavoriteFeature": "Feature1",
>   "FirstName": "Angel",
>   "Gender": "Female",
>   "LastName": "Huffman",
>   "UserName": "angelhuffman",
>   "AddressInfo": [{
>   "Address": "55 Grizzly Peak Rd.",
>   "City": {
>   "Name": "Butte",
>   "CountryRegion": "United States",
>   "Region": "MT"
>   }
>   }],
>   "HomeAddress": null
>   }]
> }
> See that 'HomeAddress' is ComplexType of type 'Location' and received 'null' 
> value.
> Similarly, ComplexType property 'City' is deserialized as Primitive Type in 
> the below response.
> "HomeAddress": {
>   "Address": null,
>   "City": null
>   }
> When you deserialize and get an entity, the HomeAddress property of the 
> Person entity is set to Primitive Type with null value. This could be complex 
> type?
> Metadata URL - http://tinyurl.com/gm8vomc



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1098) Incorrect handling of SQL wildcards '_' and '%' on filtering

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1098.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: V2 2.0.9

Fixed with commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=474d8f3e76efa01a2a267d038aaa61a3bb14244f

> Incorrect handling of SQL wildcards '_' and '%' on filtering
> 
>
> Key: OLINGO-1098
> URL: https://issues.apache.org/jira/browse/OLINGO-1098
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-jpa
>Affects Versions: V2 2.0.8
>Reporter: Ramya
>Assignee: Christian Amend
> Fix For: V2 2.0.9
>
> Attachments: JPASQLQueryFix.diff
>
>
> When an OData filter contains the SQL wildcards '%' and '_', these are 
> incorrectly translated into database queries which contain these characters 
> unescaped, leading to incorrect search results.
> Suggestion is to create positional parameterized queries.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1106) Custom Query options in batch request

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1106.
-
   Resolution: Fixed
Fix Version/s: (Java) V4 4.4.0

Resolved with commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=af116170a2fe89dbaef3f859e65d596f79206c4e

> Custom Query options in batch request
> -
>
> Key: OLINGO-1106
> URL: https://issues.apache.org/jira/browse/OLINGO-1106
> Project: Olingo
>  Issue Type: Test
>  Components: odata4-server
>Reporter: Archana Rai
>    Assignee: Christian Amend
>Priority: Minor
> Fix For: (Java) V4 4.4.0
>
> Attachments: 1357b28a.diff
>
>
> To ensure nothing breaks with the ABNF adaption/change for custom query with 
> $batch, we have added tests.
> OData V4.0 Errata 03 already explicitly allows custom query options without 
> restricting this to certain request types. See
>  
> http://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part1-protocol/odata-v4.0-errata03-os-part1-protocol-complete.html#_Toc453752212:
>  
> As per the ABNF for OData V4.01 : all requests now allow custom query 
> options. See: 
> https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/4.01%20spec/ABNF/odata-abnf-construction-rules.txt?rev=1023=0=0



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1105) Custom Query options in batch request

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1105.
-
   Resolution: Fixed
Fix Version/s: V2 2.0.9

Resolved with: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=ff4ab99569e322e0315b414e2b078d7548a7c0fb

> Custom Query options in batch request
> -
>
> Key: OLINGO-1105
> URL: https://issues.apache.org/jira/browse/OLINGO-1105
> Project: Olingo
>  Issue Type: Test
>  Components: odata2-core
>Reporter: Archana Rai
>    Assignee: Christian Amend
>Priority: Minor
> Fix For: V2 2.0.9
>
> Attachments: batchTests.diff
>
>
> As per the oasis for custom query options:
> http://www.odata.org/documentation/odata-version-2-0/uri-conventions/
> In order to verify that $batch requests can take custom query options we have 
> added the tests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (OLINGO-1106) Custom Query options in batch request

[Christian Amend (JIRA)]

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

Christian Amend reassigned OLINGO-1106:
---

Assignee: Christian Amend

> Custom Query options in batch request
> -
>
> Key: OLINGO-1106
> URL: https://issues.apache.org/jira/browse/OLINGO-1106
> Project: Olingo
>  Issue Type: Test
>  Components: odata4-server
>Reporter: Archana Rai
>    Assignee: Christian Amend
>Priority: Minor
> Attachments: 1357b28a.diff
>
>
> To ensure nothing breaks with the ABNF adaption/change for custom query with 
> $batch, we have added tests.
> OData V4.0 Errata 03 already explicitly allows custom query options without 
> restricting this to certain request types. See
>  
> http://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part1-protocol/odata-v4.0-errata03-os-part1-protocol-complete.html#_Toc453752212:
>  
> As per the ABNF for OData V4.01 : all requests now allow custom query 
> options. See: 
> https://tools.oasis-open.org/version-control/browse/wsvn/odata/trunk/4.01%20spec/ABNF/odata-abnf-construction-rules.txt?rev=1023=0=0



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (OLINGO-1105) Custom Query options in batch request

[Christian Amend (JIRA)]

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

Christian Amend reassigned OLINGO-1105:
---

Assignee: Christian Amend

> Custom Query options in batch request
> -
>
> Key: OLINGO-1105
> URL: https://issues.apache.org/jira/browse/OLINGO-1105
> Project: Olingo
>  Issue Type: Test
>  Components: odata2-core
>Reporter: Archana Rai
>    Assignee: Christian Amend
>Priority: Minor
> Attachments: batchTests.diff
>
>
> As per the oasis for custom query options:
> http://www.odata.org/documentation/odata-version-2-0/uri-conventions/
> In order to verify that $batch requests can take custom query options we have 
> added the tests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (OLINGO-1097) Failure while parsing HTTP header fields joined by multiple whitespaces

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1097:
-

Will take a look this weekend.

> Failure while parsing HTTP header fields joined by multiple whitespaces
> ---
>
> Key: OLINGO-1097
> URL: https://issues.apache.org/jira/browse/OLINGO-1097
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.8
>Reporter: Dmitry Tretyakov
>Assignee: Christian Amend
>  Labels: patch
> Fix For: V2 2.0.9
>
> Attachments: 
> 0002-OLINGO-1097-Failure-while-parsing-HTTP-header-fields.patch
>
>
> `RestUtil` while parsing HTTP header values allow to join multiple field 
> values with comma and only one white space it causes that after parsing 
> values are prefixed by white spaces which causes exceptions in `ContentType` 
> instantiation and as result leads to BadRequestException.
> See RFC 2616 4.2: 
> https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
> Example of failing HTTP accept header field value:
> {code}
> application/atom+xml,  application/xml
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (OLINGO-1097) Failure while parsing HTTP header fields joined by multiple whitespaces

[Christian Amend (JIRA)]

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

Christian Amend reassigned OLINGO-1097:
---

Assignee: Christian Amend  (was: Michael Bolz)

> Failure while parsing HTTP header fields joined by multiple whitespaces
> ---
>
> Key: OLINGO-1097
> URL: https://issues.apache.org/jira/browse/OLINGO-1097
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.8
>Reporter: Dmitry Tretyakov
>Assignee: Christian Amend
>  Labels: patch
> Fix For: V2 2.0.9
>
> Attachments: 
> 0002-OLINGO-1097-Failure-while-parsing-HTTP-header-fields.patch
>
>
> `RestUtil` while parsing HTTP header values allow to join multiple field 
> values with comma and only one white space it causes that after parsing 
> values are prefixed by white spaces which causes exceptions in `ContentType` 
> instantiation and as result leads to BadRequestException.
> See RFC 2616 4.2: 
> https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
> Example of failing HTTP accept header field value:
> {code}
> application/atom+xml,  application/xml
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1021) Unable to consume batch request with missing CRLF in request line

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1021.
-
Resolution: Fixed
  Assignee: Christian Amend

Resolved with commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=cceffb31024be8e94a210c344ee68b6b98ddfdfb

Thank you very much for the contribution!

> Unable to consume batch request with missing CRLF in request line
> -
>
> Key: OLINGO-1021
> URL: https://issues.apache.org/jira/browse/OLINGO-1021
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.7
>Reporter: Dmitry Tretyakov
>Assignee: Christian Amend
>Priority: Critical
>  Labels: patch
> Fix For: V2 2.0.9
>
> Attachments: 
> 0002-OLINGO-1021-Add-ability-to-use-non-strict-batch-pars.patch
>
>
> Currently {{BatchParser}} throws BatchException(MISSING_BLANK_LINE) when 
> request method does not end with double CRLFs and this case reproduced in the 
> test {{BatchRequestParserTest#testGetRequestMissingCRLF}}
> This behavior makes odata2-core incompatible with all implementations of .net 
> OData clients based on {{System.Data.Services.Client}} because it use only 
> one CRLF at the end of request line:
> http://referencesource.microsoft.com/#System.Data.Services.Client/Client/System/Data/Services/Client/DataServiceContext.cs,3277289aacaeb96c
> which results in the following request body:
> {code}
> --batch_86108a65-4dc2-4c0c-bd92-384be755c83a
> Content-Type: application/http
> Content-Transfer-Encoding: binary
> GET https://www.nuget.org/api/v2/Packages HTTP/1.1
> --batch_86108a65-4dc2-4c0c-bd92-384be755c83a--
> {code}
> I see that {{BatchParser}}'s constructor allows to use non strict flag, but 
> at the moment it's impossible to set due to hardcoded value in 
> ProviderFacadeImpl#parseBatchRequest method.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (OLINGO-1021) Unable to consume batch request with missing CRLF in request line

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1021:
-

Then I would make this change as I don`t want to change the default behavior 
that we currently have.

> Unable to consume batch request with missing CRLF in request line
> -
>
> Key: OLINGO-1021
> URL: https://issues.apache.org/jira/browse/OLINGO-1021
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.7
>Reporter: Dmitry Tretyakov
>Priority: Critical
>  Labels: patch
> Fix For: V2 2.0.9
>
> Attachments: 
> 0002-OLINGO-1021-Add-ability-to-use-non-strict-batch-pars.patch
>
>
> Currently {{BatchParser}} throws BatchException(MISSING_BLANK_LINE) when 
> request method does not end with double CRLFs and this case reproduced in the 
> test {{BatchRequestParserTest#testGetRequestMissingCRLF}}
> This behavior makes odata2-core incompatible with all implementations of .net 
> OData clients based on {{System.Data.Services.Client}} because it use only 
> one CRLF at the end of request line:
> http://referencesource.microsoft.com/#System.Data.Services.Client/Client/System/Data/Services/Client/DataServiceContext.cs,3277289aacaeb96c
> which results in the following request body:
> {code}
> --batch_86108a65-4dc2-4c0c-bd92-384be755c83a
> Content-Type: application/http
> Content-Transfer-Encoding: binary
> GET https://www.nuget.org/api/v2/Packages HTTP/1.1
> --batch_86108a65-4dc2-4c0c-bd92-384be755c83a--
> {code}
> I see that {{BatchParser}}'s constructor allows to use non strict flag, but 
> at the moment it's impossible to set due to hardcoded value in 
> ProviderFacadeImpl#parseBatchRequest method.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (OLINGO-1021) Unable to consume batch request with missing CRLF in request line

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1021:
-

Hi Dmitry,

thanks for the patch :) I will look at it this evening. 

What is the default now after your contribution? Strict or non-strict?

Best Regards,
Christian

> Unable to consume batch request with missing CRLF in request line
> -
>
> Key: OLINGO-1021
> URL: https://issues.apache.org/jira/browse/OLINGO-1021
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.7
>Reporter: Dmitry Tretyakov
>Priority: Critical
>  Labels: patch
> Fix For: V2 2.0.9
>
> Attachments: 
> 0002-OLINGO-1021-Add-ability-to-use-non-strict-batch-pars.patch
>
>
> Currently {{BatchParser}} throws BatchException(MISSING_BLANK_LINE) when 
> request method does not end with double CRLFs and this case reproduced in the 
> test {{BatchRequestParserTest#testGetRequestMissingCRLF}}
> This behavior makes odata2-core incompatible with all implementations of .net 
> OData clients based on {{System.Data.Services.Client}} because it use only 
> one CRLF at the end of request line:
> http://referencesource.microsoft.com/#System.Data.Services.Client/Client/System/Data/Services/Client/DataServiceContext.cs,3277289aacaeb96c
> which results in the following request body:
> {code}
> --batch_86108a65-4dc2-4c0c-bd92-384be755c83a
> Content-Type: application/http
> Content-Transfer-Encoding: binary
> GET https://www.nuget.org/api/v2/Packages HTTP/1.1
> --batch_86108a65-4dc2-4c0c-bd92-384be755c83a--
> {code}
> I see that {{BatchParser}}'s constructor allows to use non strict flag, but 
> at the moment it's impossible to set due to hardcoded value in 
> ProviderFacadeImpl#parseBatchRequest method.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (OLINGO-1021) Unable to consume batch request with missing CRLF in request line

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1021:
-

Hi Dmitry,

thanks for the patch :) I will look at it this evening. 

What is the default now after your contribution? Strict or non-strict?

Best Regards,
Christian

> Unable to consume batch request with missing CRLF in request line
> -
>
> Key: OLINGO-1021
> URL: https://issues.apache.org/jira/browse/OLINGO-1021
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.7
>Reporter: Dmitry Tretyakov
>Priority: Critical
>  Labels: patch
> Fix For: V2 2.0.9
>
> Attachments: 
> 0002-OLINGO-1021-Add-ability-to-use-non-strict-batch-pars.patch
>
>
> Currently {{BatchParser}} throws BatchException(MISSING_BLANK_LINE) when 
> request method does not end with double CRLFs and this case reproduced in the 
> test {{BatchRequestParserTest#testGetRequestMissingCRLF}}
> This behavior makes odata2-core incompatible with all implementations of .net 
> OData clients based on {{System.Data.Services.Client}} because it use only 
> one CRLF at the end of request line:
> http://referencesource.microsoft.com/#System.Data.Services.Client/Client/System/Data/Services/Client/DataServiceContext.cs,3277289aacaeb96c
> which results in the following request body:
> {code}
> --batch_86108a65-4dc2-4c0c-bd92-384be755c83a
> Content-Type: application/http
> Content-Transfer-Encoding: binary
> GET https://www.nuget.org/api/v2/Packages HTTP/1.1
> --batch_86108a65-4dc2-4c0c-bd92-384be755c83a--
> {code}
> I see that {{BatchParser}}'s constructor allows to use non strict flag, but 
> at the moment it's impossible to set due to hardcoded value in 
> ProviderFacadeImpl#parseBatchRequest method.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1094) Key predicate for Edm.String type

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1094.
-
Resolution: Information Provided

Currently all types are returned in the URI format. I would prefer a method to 
get it as a data object instead. 

As a workaround you can use the valueOfString method at the PrimitiveType 
instance to get the unquoted value. Just pass type URI to the method to make 
sure that the method knows it is parsing a URI type of value.

If you want to contribute a patch that returns the proper values for all EDM 
Types I can apply it to the master branch. Just stick to the guideline and 
include a test case please :)

> Key predicate for Edm.String type
> -
>
> Key: OLINGO-1094
> URL: https://issues.apache.org/jira/browse/OLINGO-1094
> Project: Olingo
>  Issue Type: Bug
>Reporter: Jay Xu
>    Assignee: Christian Amend
>
> I defined a entitytype `Product` and have a property `Id` which type is 
> defined as Edm.String. When I set this property as a CsdlPropertyRef, and 
> have the entity in which the value of the property 'Id' is the String 
> `Simple`. According to the function 'nextStringValue' of 
> olingo.server.core.uri.parser.UriTkoenizer, seems that it only allows the URI 
> `//Product)('Simple')`. Is it possible to just simplify the URI as 
> `//Product)(Simple)`, that is, removing the single quotation around 
> Simple? Because when query the value of the property `Id`, it shows me only 
> the word Simple.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1094) Key predicate for Edm.String type

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1094.
-
Resolution: Not A Problem
  Assignee: Christian Amend

Hi Jay,

the URI specification says that key predicates of the type string must be in 
single quotation marks. So there is no way to get around this.

Best Regards,
Christian

> Key predicate for Edm.String type
> -
>
> Key: OLINGO-1094
> URL: https://issues.apache.org/jira/browse/OLINGO-1094
> Project: Olingo
>  Issue Type: Bug
>Reporter: Jay Xu
>    Assignee: Christian Amend
>
> I defined a entitytype `Product` and have a property `Id` which type is 
> defined as Edm.String. When I set this property as a CsdlPropertyRef, and 
> have the entity in which the value of the property 'Id' is the String 
> `Simple`. According to the function 'nextStringValue' of 
> olingo.server.core.uri.parser.UriTkoenizer, seems that it only allows the URI 
> `//Product)('Simple')`. Is it possible to just simplify the URI as 
> `//Product)(Simple)`, that is, removing the single quotation around 
> Simple? Because when query the value of the property `Id`, it shows me only 
> the word Simple.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1092) Remove addition of extra slash when the servlet path does not have preceeding segments

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1092.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: V2 2.0.9

Thanks for providing a patch with a test. I have applied the patch with the 
following commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=22e787318d3a8cf067542ef232f3f359cb122dd7

> Remove addition of extra slash when the servlet path does not have preceeding 
> segments
> --
>
> Key: OLINGO-1092
> URL: https://issues.apache.org/jira/browse/OLINGO-1092
> Project: Olingo
>  Issue Type: Bug
>Affects Versions: V2 2.0.6
>Reporter: Ramya
>Assignee: Christian Amend
> Fix For: V2 2.0.9
>
> Attachments: 4385a377.diff
>
>
> When url is of the form ;v=1 olingo adds an extra slash like 
> /;v=1 while creating the baseUrl.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (OLINGO-1092) Remove addition of extra slash when the servlet path does not have preceeding segments

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1092:
-

Hi

thanks for the contribution. The patch does not contain a test to ensure the 
new functionality does not get broken by future commits. Could you please 
attach a patch which contains a test?
This is according to our guidelines at http://olingo.apache.org/contribute.html

Thanks & Best Regards,
Christian 

> Remove addition of extra slash when the servlet path does not have preceeding 
> segments
> --
>
> Key: OLINGO-1092
> URL: https://issues.apache.org/jira/browse/OLINGO-1092
> Project: Olingo
>  Issue Type: Bug
>Affects Versions: V2 2.0.6
>Reporter: Ramya
> Attachments: b5e84597.diff
>
>
> When url is of the form ;v=1 olingo adds an extra slash like 
> /;v=1 while creating the baseUrl.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1091) Accept language having aplha numeric values throws invalid Accept-Language

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1091.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: V2 2.0.9

Thanks for the contribution. I applied the patch with the following commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=14ef0cdda6d5155d0bc6811942b1606e22c5c0a3

> Accept language having aplha numeric values throws invalid Accept-Language
> --
>
> Key: OLINGO-1091
> URL: https://issues.apache.org/jira/browse/OLINGO-1091
> Project: Olingo
>  Issue Type: Bug
>Affects Versions: V2 2.0.6, V2 2.0.7, V2 2.0.8
>Reporter: Ramya
>    Assignee: Christian Amend
> Fix For: V2 2.0.9
>
> Attachments: 3f0e9eff.diff
>
>
> When Accept-Language with value es-419 (latin-american) is set the batch 
> request header then parsing works fine. However, when Accept-Language with 
> value es-419 is given as a header in batch request payload parsing fails.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1090) Incorrect batch error response when content type is json verbose

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1090.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: V2 2.0.9

Thanks for the contribution. I applied the patch with the follwoing commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=cd4a0752c7adec31b7bff08b1e6e575b5c8e73fb

> Incorrect batch error response when content type is json verbose
> 
>
> Key: OLINGO-1090
> URL: https://issues.apache.org/jira/browse/OLINGO-1090
> Project: Olingo
>  Issue Type: Bug
>Affects Versions: V2 2.0.8
>Reporter: Ramya
>    Assignee: Christian Amend
> Fix For: V2 2.0.9
>
> Attachments: 980bc042.diff
>
>
> When DataServiceVersion is 2.0 and MaxDataServiceVersion is 3.0 and if the 
> obtained response has to be of type json verbose then it becomes necessary to 
> add the header Accept: application/json;odata=verbose.
> In case of batch requests, when a request fails the error message is obtained 
> in xml format instead of json.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-950) Using both $top and $inlinecount writes a __next link

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-950.

Resolution: Information Provided

Information seems to be provided. If still relevant please reopen :)

> Using both $top and $inlinecount writes a __next link
> -
>
> Key: OLINGO-950
> URL: https://issues.apache.org/jira/browse/OLINGO-950
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.6
>Reporter: Peter Rilling
>
> Using both $top and $inlinecount writes a __next link.  From what I 
> understand, $top/$skip are supposed to enable client paging, so the server 
> should not send "next" link.  Without $inlinecount, this is true, but add 
> that option and the "next" link is written.
> I am comparing this to the following service, which does not have the "next" 
> link:
> http://services.odata.org/V2/Northwind/Northwind.svc/Customers?$format=json&$inlinecount=allpages&$top=2



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1080) Support Entity Iterator in batch

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1080.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: (Java) V4 4.4.0

Hi thanks for the patch with tests. I applied it with the following commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=89a6a69de7a8c57fc4d2f59012019395ef2e001f

> Support Entity Iterator in batch
> 
>
> Key: OLINGO-1080
> URL: https://issues.apache.org/jira/browse/OLINGO-1080
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-server
>Affects Versions: (Java) V4 4.3.0
>Reporter: Ramya
>Assignee: Christian Amend
> Fix For: (Java) V4 4.4.0
>
> Attachments: 646dbf95.diff
>
>
> When there is a GET request on an Entity for which streaming is enabled, 
> batch request does not return the response.
> This issue is to support Entity Iterator within batch requests.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (OLINGO-1087) Precision in EdmDecimal not calculated correctly

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1087:
-

The V2 specification pdf is not available on the website anymore and the html 
version does not have this paragraph: 
2.2.1.7.1.1 Precision
This is a positive integer that specifies the maximum number of decimal digits 
that an instance of the decimal type can have, both to the left and to the 
right of the decimal point. Possible values for Precision are 1, 2, or 3.

V3 specifies it as follows: 
2.2.1.7.1.1 Precision
The Precision facet is a positive integer that specifies the maximum number of 
decimal digits that an instance of the decimal type can have, both to the left 
and to the right of the decimal point.

And V4 is online available: 
http://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part3-csdl/odata-v4.0-errata03-os-part3-csdl-complete.html#_Toc453752531
For a decimal property the value of this attribute specifies the maximum number 
of significant decimal digits of the property’s value; it MUST be a positive 
integer. If no value is specified, the decimal property has unspecified 
precision.

We only evaluate this because it is part of the specification.  You can disable 
the Facet validation by setting the flag at the EntityProviderReadProperties 
with the isValidatingFacets(boolean) method. 

I will check with the OData specification people to see what they meant with 
significant. I assumed the arithmetic definition: 
https://simple.wikipedia.org/wiki/Arithmetic_precision as opposed to this 
definition: https://en.wikipedia.org/wiki/Significant_figures

I would not like to introduce something which goes against the specification.

> Precision in EdmDecimal not calculated correctly
> 
>
> Key: OLINGO-1087
> URL: https://issues.apache.org/jira/browse/OLINGO-1087
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.8
>Reporter: Svante von Erichsen
> Attachments: 0001-OLINGO-1087-Fix-calculation-of-precision.patch
>
>
> The "precision" found in a read number is currently at least the number of 
> decimals (omitting trailing zeroes).  That seems to be wrong, or at least not 
> consistent with at least some server side view of the matter, for numbers 
> smaller than 0.1 (the number shown has 35 decimals, but precision 34):
> org.apache.olingo.odata2.api.edm.EdmSimpleTypeException: The metadata 
> constraints '[Precision=34]' do not match the literal 
> '0.081023599170194880411145277'.
> at 
> org.apache.olingo.odata2.core.edm.EdmDecimal.internalValueOfString(EdmDecimal.java:107)
> at 
> org.apache.olingo.odata2.core.edm.AbstractSimpleType.valueOfString(AbstractSimpleType.java:91)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonPropertyConsumer.readSimpleProperty(JsonPropertyConsumer.java:236)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonPropertyConsumer.readPropertyValue(JsonPropertyConsumer.java:169)
> ... 69 common frames omitted
> Wrapped by: org.apache.olingo.odata2.api.ep.EntityProviderException: An 
> exception of type 'EdmSimpleTypeException' occurred.
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonPropertyConsumer.readPropertyValue(JsonPropertyConsumer.java:171)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntryConsumer.handleName(JsonEntryConsumer.java:172)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntryConsumer.readEntryContent(JsonEntryConsumer.java:130)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntryConsumer.readFeedEntry(JsonEntryConsumer.java:117)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonFeedConsumer.readArrayContent(JsonFeedConsumer.java:153)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonFeedConsumer.handleName(JsonFeedConsumer.java:122)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonFeedConsumer.readFeedContent(JsonFeedConsumer.java:111)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonFeedConsumer.readFeed(JsonFeedConsumer.java:96)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonFeedConsumer.readFeedStandalone(JsonFeedConsumer.java:63)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntityConsumer.readDeltaFeed(JsonEntityConsumer.java:95)
> at 
> org.apache.olingo.odata2.core.ep.consumer.JsonEntityConsumer.readFeed(JsonEntityConsumer.ja

[jira] [Resolved] (OLINGO-1088) Improve V2 serialization error messages

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1088.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: V2 2.0.9

thanks for contributing and including a test :)

I applied the patch with the following commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=742560d27b5498860a9fb4d63eb11f8cf1d294dd

> Improve V2 serialization error messages
> ---
>
> Key: OLINGO-1088
> URL: https://issues.apache.org/jira/browse/OLINGO-1088
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.6, V2 2.0.7, V2 2.0.8
>Reporter: Ramya
>Assignee: Christian Amend
> Fix For: V2 2.0.9
>
> Attachments: 1ddfed0f.diff
>
>
> Provide better error messages when the serializer fails due to wrong property 
> content. The message should at least contain the property name.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1086) How to control presence of OData error details

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1086.
-
Resolution: Information Provided

> How to control presence of OData error details
> --
>
> Key: OLINGO-1086
> URL: https://issues.apache.org/jira/browse/OLINGO-1086
> Project: Olingo
>  Issue Type: Question
>  Components: odata2-core
>Affects Versions: V2 2.0.6
>Reporter: ashish
>Assignee: Christian Amend
>Priority: Minor
>
> I'm trying to control the presence of details in error responses from When I  
> I would like to get something like this:
> {
>   "error": {
> "code": "Error code",
> "message": "Message from exception filter",
> "details": [
>   {
> "code": "Detail code",
> "message": "Details here"
>   }
> ],
> "innererror": {
>   "message": "Exception message here",
>   "type": "Exception type",
>   "stacktrace": "Stack trace here"
> }
>   }
> }
> But i am getting like:
> {
>   "error": {
> "code": "Error code",
> "message": "Message from exception filter"
>   }
> }
> I Followed https://olingo.apache.org/doc/odata2/tutorials/debug.html for 
> callback method but ODataErrorContext  class do not have any method to set 
> Error_details .
> can you please help me here?
> Thanks in advance.
> Ashish 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (OLINGO-1086) How to control presence of OData error details

[Christian Amend (JIRA)]

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

Christian Amend reassigned OLINGO-1086:
---

Assignee: Christian Amend

Hi Ashish,

this feature is not yet implemented. If you would like to contribute a patch 
file which implements this here is a tutorial you can follow: 
http://olingo.apache.org/contribute.html

Thanks & Best Regards,
Chris

> How to control presence of OData error details
> --
>
> Key: OLINGO-1086
> URL: https://issues.apache.org/jira/browse/OLINGO-1086
> Project: Olingo
>  Issue Type: Question
>  Components: odata2-core
>Affects Versions: V2 2.0.6
>Reporter: ashish
>Assignee: Christian Amend
>Priority: Minor
>
> I'm trying to control the presence of details in error responses from When I  
> I would like to get something like this:
> {
>   "error": {
> "code": "Error code",
> "message": "Message from exception filter",
> "details": [
>   {
> "code": "Detail code",
> "message": "Details here"
>   }
> ],
> "innererror": {
>   "message": "Exception message here",
>   "type": "Exception type",
>   "stacktrace": "Stack trace here"
> }
>   }
> }
> But i am getting like:
> {
>   "error": {
> "code": "Error code",
> "message": "Message from exception filter"
>   }
> }
> I Followed https://olingo.apache.org/doc/odata2/tutorials/debug.html for 
> callback method but ODataErrorContext  class do not have any method to set 
> Error_details .
> can you please help me here?
> Thanks in advance.
> Ashish 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1079) edmx Reference tag Issue

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1079.
-
   Resolution: Fixed
Fix Version/s: V2 2.0.9

As there were no objections I merged the patch with the following commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=ee4b64337a35898a84508180d4f4e73d407c42e0

> edmx Reference tag Issue
> 
>
> Key: OLINGO-1079
> URL: https://issues.apache.org/jira/browse/OLINGO-1079
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Reporter: Archana Rai
>    Assignee: Christian Amend
> Fix For: V2 2.0.9
>
> Attachments: e488eb6c.diff
>
>
> Olingo version 2.0 validation as validation failes the edmx due to prefix 
> mentioned as below.
> Ex:
> {code}
> http://schemas.microsoft.com/ado/2007/06/edmx; 
> xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata; 
> xmlns:sap="http://www.sap.com/Protocols/SAPData; Version="1.0">
> http://docs.oasis-open.org/odata/ns/edmx; 
> Uri="https://host:port/sap/opu/odata/IWFND/CATALOGSERVICE;v=2/Vocabularies(TechnicalName='%2FIWBEP%2FVOC_COMMON',Version='0001',SAP__Origin='')/$value">
> 
> 
> {code}
> edmx:Reference tags are not supported by the OData V2 specification.
> The root Edmx element is using the OData V2 Edmx namespace with namespace 
> prefix edmx:
> http://schemas.microsoft.com/ado/2007/06/edmx;
> The nested Reference element is using the OData V4 Edmx namespace and 
> redefines the edmx: prefix
> http://docs.oasis-open.org/odata/ns/edmx;
> A better prefix choice would have been edmx4: or anything except edmx:, but 
> the XML document is nevertheless correct.
> Section 1.7 of the OData V2 Edmx specification says in 
> https://msdn.microsoft.com/en-us/library/dd541467.aspx
> Parsers of EDMX documents ignore content that is unexpected or that cannot be 
> parsed.
> So skipping unknown tags should be the default behavior of the Olingo Edmx 
> parser.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (OLINGO-1079) edmx Reference tag Issue

[Christian Amend (JIRA)]

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

Christian Amend reassigned OLINGO-1079:
---

Assignee: Christian Amend

> edmx Reference tag Issue
> 
>
> Key: OLINGO-1079
> URL: https://issues.apache.org/jira/browse/OLINGO-1079
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Reporter: Archana Rai
>    Assignee: Christian Amend
> Attachments: e488eb6c.diff
>
>
> Olingo version 2.0 validation as validation failes the edmx due to prefix 
> mentioned as below.
> Ex:
> {code}
> http://schemas.microsoft.com/ado/2007/06/edmx; 
> xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata; 
> xmlns:sap="http://www.sap.com/Protocols/SAPData; Version="1.0">
> http://docs.oasis-open.org/odata/ns/edmx; 
> Uri="https://host:port/sap/opu/odata/IWFND/CATALOGSERVICE;v=2/Vocabularies(TechnicalName='%2FIWBEP%2FVOC_COMMON',Version='0001',SAP__Origin='')/$value">
> 
> 
> {code}
> edmx:Reference tags are not supported by the OData V2 specification.
> The root Edmx element is using the OData V2 Edmx namespace with namespace 
> prefix edmx:
> http://schemas.microsoft.com/ado/2007/06/edmx;
> The nested Reference element is using the OData V4 Edmx namespace and 
> redefines the edmx: prefix
> http://docs.oasis-open.org/odata/ns/edmx;
> A better prefix choice would have been edmx4: or anything except edmx:, but 
> the XML document is nevertheless correct.
> Section 1.7 of the OData V2 Edmx specification says in 
> https://msdn.microsoft.com/en-us/library/dd541467.aspx
> Parsers of EDMX documents ignore content that is unexpected or that cannot be 
> parsed.
> So skipping unknown tags should be the default behavior of the Olingo Edmx 
> parser.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (OLINGO-1079) edmx Reference tag Issue

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1079:
-

I checked with Ralf Handl to see if such a metadata document is valid. As long 
as the xml is correct the parser shouldn`t fail during validation. I had a look 
at the patch. It only skips the unkown tags from the different namspace but 
does not introduce V4 features into the V2 library. So from my side I would be 
OK to apply it.

> edmx Reference tag Issue
> 
>
> Key: OLINGO-1079
> URL: https://issues.apache.org/jira/browse/OLINGO-1079
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Reporter: Archana Rai
> Attachments: e488eb6c.diff
>
>
> Olingo version 2.0 validation as validation failes the edmx due to prefix 
> mentioned as below.
> Ex:
> {code}
> http://schemas.microsoft.com/ado/2007/06/edmx; 
> xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata; 
> xmlns:sap="http://www.sap.com/Protocols/SAPData; Version="1.0">
> http://docs.oasis-open.org/odata/ns/edmx; 
> Uri="https://host:port/sap/opu/odata/IWFND/CATALOGSERVICE;v=2/Vocabularies(TechnicalName='%2FIWBEP%2FVOC_COMMON',Version='0001',SAP__Origin='')/$value">
> 
> 
> {code}
> edmx:Reference tags are not supported by the OData V2 specification.
> The root Edmx element is using the OData V2 Edmx namespace with namespace 
> prefix edmx:
> http://schemas.microsoft.com/ado/2007/06/edmx;
> The nested Reference element is using the OData V4 Edmx namespace and 
> redefines the edmx: prefix
> http://docs.oasis-open.org/odata/ns/edmx;
> A better prefix choice would have been edmx4: or anything except edmx:, but 
> the XML document is nevertheless correct.
> Section 1.7 of the OData V2 Edmx specification says in 
> https://msdn.microsoft.com/en-us/library/dd541467.aspx
> Parsers of EDMX documents ignore content that is unexpected or that cannot be 
> parsed.
> So skipping unknown tags should be the default behavior of the Olingo Edmx 
> parser.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1077) OData V4.0: EntityIterator count support

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1077.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: (Java) V4 4.4.0

Thanks for the patch :)

> OData V4.0: EntityIterator count support
> 
>
> Key: OLINGO-1077
> URL: https://issues.apache.org/jira/browse/OLINGO-1077
> Project: Olingo
>  Issue Type: New Feature
>  Components: odata4-server
>Reporter: Archana Rai
>    Assignee: Christian Amend
> Fix For: (Java) V4 4.4.0
>
> Attachments: 6efd0282.diff
>
>
> The current EntityIterator class does not support count. Provide a provision 
> to set count in EntityIterartor.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (OLINGO-1056) Batch requests/responses on client

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1056.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: V2 2.0.9

Hi,

you can use the EntityProvider.write... methods to transform the objects. then 
you take the input stream and transform it into a String.

If you would like to have a better API you could contribute a patch for this.

Best Regards,
Christian

> Batch requests/responses on client
> --
>
> Key: OLINGO-1056
> URL: https://issues.apache.org/jira/browse/OLINGO-1056
> Project: Olingo
>  Issue Type: Question
>  Components: odata2-core
>Affects Versions: V2 2.0.7
>Reporter: M Carissimi
>Assignee: Christian Amend
> Fix For: V2 2.0.9
>
>
> Hello,
> we have implemented an OData 2 service that supports batch operations. We are 
> now writing an OData client to create a batch request and parse a batch 
> response.
> The body of the batch request needs to be provided as JSON/XML text. Is there 
> an easy way to convert objects (like ODataEntry or ODataFeed) into a JSON/XML 
> string that can be added as the body of our batch request?
> When parsing the response body, is there a way to convert the body text into 
> objects like ODataEntry or ODataFeed?
> Thanks
> Michele



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1025) Issue in Excel with relative context URI

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1025.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: V2 2.0.9

Hi,

You can use the "serviceRoot(URI)" method in the builder to get absolute URLs.

Best Regards,
Christian

> Issue in Excel with relative context URI
> 
>
> Key: OLINGO-1025
> URL: https://issues.apache.org/jira/browse/OLINGO-1025
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-server
>Affects Versions: (Java) V4 4.3.0
>Reporter: Olivier VERMONT
>Assignee: Christian Amend
> Fix For: V2 2.0.9
>
>
> Hi Olingo Team,
> I'm trying out your library to publish an odata v4 stream to Excel Power 
> Query.
> I started with your tutorial and ran into this first issue : Excel requires 
> absolute metadata URL in service document which I solved by creating a custom 
> processor as indicated here : https://issues.apache.org/jira/browse/OLINGO-758
> That enabled me to go one step further but I got stuck again when I requested 
> /Products because of the m:context which also seems to be relative : 
> m:context="$metadata#Products"
> I tried playing with the ContextURL but I only managed to come up with this 
> which Excel doesn't like either : m:context="../../../../$metadata#Products 
> Here is the code in the DemoEntityCollectionProcessor.java :
> ContextURL contextUrl = 
> ContextURL.with().entitySet(edmEntitySet).oDataPath(request.getRawBaseUri()).build();
> EntitySerializerOptions options = 
> EntitySerializerOptions.with().contextURL(contextUrl).build();
> Here is the message I get in Excel :
> DataSource.Error: OData : The top level context URL '$metadata#Products' 
> should be an absolute Uri.
> Détails :
> DataSourceKind=OData
> 
> DataSourcePath=http://mydomain.net/Developpement/SettOData.nsf/odata.xsp/Products
> Could anyone please help me to solve this issue ?
> Regards,



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OLINGO-1025) Issue in Excel with relative context URI

[Christian Amend (JIRA)]

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

Christian Amend updated OLINGO-1025:

Issue Type: Question  (was: Bug)

> Issue in Excel with relative context URI
> 
>
> Key: OLINGO-1025
> URL: https://issues.apache.org/jira/browse/OLINGO-1025
> Project: Olingo
>  Issue Type: Question
>  Components: odata4-server
>Affects Versions: (Java) V4 4.3.0
>Reporter: Olivier VERMONT
>Assignee: Christian Amend
> Fix For: V2 2.0.9
>
>
> Hi Olingo Team,
> I'm trying out your library to publish an odata v4 stream to Excel Power 
> Query.
> I started with your tutorial and ran into this first issue : Excel requires 
> absolute metadata URL in service document which I solved by creating a custom 
> processor as indicated here : https://issues.apache.org/jira/browse/OLINGO-758
> That enabled me to go one step further but I got stuck again when I requested 
> /Products because of the m:context which also seems to be relative : 
> m:context="$metadata#Products"
> I tried playing with the ContextURL but I only managed to come up with this 
> which Excel doesn't like either : m:context="../../../../$metadata#Products 
> Here is the code in the DemoEntityCollectionProcessor.java :
> ContextURL contextUrl = 
> ContextURL.with().entitySet(edmEntitySet).oDataPath(request.getRawBaseUri()).build();
> EntitySerializerOptions options = 
> EntitySerializerOptions.with().contextURL(contextUrl).build();
> Here is the message I get in Excel :
> DataSource.Error: OData : The top level context URL '$metadata#Products' 
> should be an absolute Uri.
> Détails :
> DataSourceKind=OData
> 
> DataSourcePath=http://mydomain.net/Developpement/SettOData.nsf/odata.xsp/Products
> Could anyone please help me to solve this issue ?
> Regards,



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1061) POST and PUT for data feed

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1061.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: V2 2.0.9

OData does not allow you to create a collection of entities within one requests.

The closest you can get to this is by sending a batch requests which contains 
each single request for all the entities you want to create.

Best Regards,
Christian

> POST and PUT for data feed
> --
>
> Key: OLINGO-1061
> URL: https://issues.apache.org/jira/browse/OLINGO-1061
> Project: Olingo
>  Issue Type: Question
>  Components: odata2-core
>Affects Versions: V2 2.0.7
>Reporter: M Carissimi
>Assignee: Christian Amend
> Fix For: V2 2.0.9
>
>
> Hello,
> we are writing an application that interfaces with our OData service. Both 
> the consumer and producer sides have been written using Olingo. We need to be 
> able to post/put a collection of entries to be stored atomically. How can 
> this be achieved? 
> The interfaces provided by the Olingo library (EntityProcessor, 
> EntitySetProcessor) only support create, update and delete methods for single 
> entries. Are there equivalent methods for collection of entries?
> Thank you



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1067) Availability of @odata.type in the response payload

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1067.
-
Resolution: Fixed
  Assignee: Christian Amend

By using odata.metadata=full as parameter which you use to create the 
serializer. But you should not send that manually. You should send back what 
the client requests.

> Availability of @odata.type in the response payload
> ---
>
> Key: OLINGO-1067
> URL: https://issues.apache.org/jira/browse/OLINGO-1067
> Project: Olingo
>  Issue Type: Question
>  Components: odata4-server
>Affects Versions: (Java) V4 4.3.0
>Reporter: VIJAYASIMHA R NAGA
>Assignee: Christian Amend
>
> Currently the Serializer only includes @odata.type in the response payload if 
> the value of Entity is an derived instance of the requested EntityType, is 
> there a way to always include @odata.type in the response payload?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OLINGO-1068) EntityProvider writeEntry does not include inline content in ODataResponse

[Christian Amend (JIRA)]

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

Christian Amend updated OLINGO-1068:

Issue Type: Question  (was: Bug)

> EntityProvider writeEntry does not include inline content in ODataResponse
> --
>
> Key: OLINGO-1068
> URL: https://issues.apache.org/jira/browse/OLINGO-1068
> Project: Olingo
>  Issue Type: Question
>  Components: odata2-core
>Affects Versions: V2 2.0.8
>Reporter: M Carissimi
>Assignee: Christian Amend
>
> Hello,
> I have an OData client written using the Olingo library that takes a set of 
> properties (Map<String,Objects>) and uses it to put data to a OData server.
> The EntityProvider.writeEntry() method is used to obtain an InputStream for 
> the set of properties to send to the server:
> {code}
>   public ConsumerResponse updateEntry(String anEntitySetName, String 
> anEntryURL, Map<String, Object> someData,
>   String aContentType) throws ConsumerException
>   {
> ConsumerResponse myConsumerResponse = null;
> try
> {
>   EdmEntityContainer myEntityContainer = 
> getMetadata(anEntryURL).getDefaultEntityContainer();
>   EntityProviderWriteProperties myWriteProperties = 
>   EntityProviderWriteProperties.serviceRoot(new 
> URI(extractServiceURIFromURL(anEntryURL))).build();
>   
>   // serialize data into ODataResponse object
>   ODataResponse myResponse = EntityProvider.writeEntry(aContentType, 
>   myEntityContainer.getEntitySet(anEntitySetName), someData, 
> myWriteProperties);
>   // get entity InputStream
>   InputStream myEntity = (InputStream) myResponse.getEntity();
>   
>   // put data to server
>   HttpResponse myHttpResponse = execute(anEntryURL, HTTP_METHOD_PUT, 
> myEntity, aContentType);
> ...
> {code}
> This works well for single entries, but it does not work for entries with 
> inline content. If the set of properties contain both simple properties (e.g: 
> NAME > "MyName") and inline content (e.g. ENTITY_LINK > Map<String,Object>), 
> the ODataResponse object returned by the EntityProvider.writeEntry() method, 
> does not include the inline content.
> I have attempted to set the inline content as an ODataEntry object rather 
> than a Map<String,Object> but the behaviour is the same.
> Why is the inline content not retained by the writeEntry() method?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1035) Support creating entities with inline URIs to existing entities

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1035.
-
Resolution: Fixed
  Assignee: Christian Amend

Resolved with commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=d6f9ddeedb928b32c0ef2f3ea0dbf0ea056b9d3a

Thanks for the patch.

> Support creating entities with inline URIs to existing entities
> ---
>
> Key: OLINGO-1035
> URL: https://issues.apache.org/jira/browse/OLINGO-1035
> Project: Olingo
>  Issue Type: Improvement
>  Components: odata2-annotation
>Affects Versions: V2 2.0.7
>Reporter: Michael Strasser
>Assignee: Christian Amend
>Priority: Minor
> Fix For: V2 2.0.9
>
> Attachments: 
> 0001-OLINGO-1035-Accept-inline-URI-to-create-a-reference-.patch
>
>
> Adding support for posting entities with URI references to other entities.
> For example, given a *Building* posted to {{/Test.svc/Buildings}} with:
> {code:javascript}
> {
>   "Id": "B01",
>   "Name": "Building 1"
> }
> {code}
> it is possible to add a *Room* to {{/Test.svc/Rooms}} with:
> {code:javascript}
> {
>   "Id": "R01-01",
>   "Name": "Room 01",
>   "Building": {
> "__metadata": {
>   "uri": "Buildings('B01')"
> }
>   }
> }
> {code}
> and have the new entity reference the existing one correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1054) Inline Consumer Callback Data handling

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1054.
-
Resolution: Fixed
  Assignee: Christian Amend

Resolved with this commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=f24fc8bf42aa225afee2913e47423f11dc9fc237

Thanks for the patch.

> Inline Consumer Callback Data handling
> --
>
> Key: OLINGO-1054
> URL: https://issues.apache.org/jira/browse/OLINGO-1054
> Project: Olingo
>  Issue Type: New Feature
>  Components: odata2-core
>Affects Versions: V2 2.0.6, V2 2.0.7
>Reporter: Ramya
>Assignee: Christian Amend
> Fix For: V2 2.0.9
>
> Attachments: 626b49ed.diff
>
>
> When using the consumer callbacks the data is not part of the result. Yet 
> since there is no access to the parent data the callback can`t decide where 
> to put the data.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OLINGO-1035) Support creating entities with inline URIs to existing entities

[Christian Amend (JIRA)]

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

Christian Amend updated OLINGO-1035:

Fix Version/s: (was: V2 2.0.8)
   V2 2.0.9

> Support creating entities with inline URIs to existing entities
> ---
>
> Key: OLINGO-1035
> URL: https://issues.apache.org/jira/browse/OLINGO-1035
> Project: Olingo
>  Issue Type: Improvement
>  Components: odata2-annotation
>Affects Versions: V2 2.0.7
>Reporter: Michael Strasser
>Priority: Minor
> Fix For: V2 2.0.9
>
> Attachments: 
> 0001-OLINGO-1035-Accept-inline-URI-to-create-a-reference-.patch
>
>
> Adding support for posting entities with URI references to other entities.
> For example, given a *Building* posted to {{/Test.svc/Buildings}} with:
> {code:javascript}
> {
>   "Id": "B01",
>   "Name": "Building 1"
> }
> {code}
> it is possible to add a *Room* to {{/Test.svc/Rooms}} with:
> {code:javascript}
> {
>   "Id": "R01-01",
>   "Name": "Room 01",
>   "Building": {
> "__metadata": {
>   "uri": "Buildings('B01')"
> }
>   }
> }
> {code}
> and have the new entity reference the existing one correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (OLINGO-1021) Unable to consume batch request with missing CRLF in request line

[Christian Amend (JIRA)]

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

Christian Amend updated OLINGO-1021:

Fix Version/s: (was: V2 2.0.8)
   V2 2.0.9

> Unable to consume batch request with missing CRLF in request line
> -
>
> Key: OLINGO-1021
> URL: https://issues.apache.org/jira/browse/OLINGO-1021
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.7
>Reporter: Dmitry Tretyakov
>Priority: Critical
> Fix For: V2 2.0.9
>
>
> Currently {{BatchParser}} throws BatchException(MISSING_BLANK_LINE) when 
> request method does not end with double CRLFs and this case reproduced in the 
> test {{BatchRequestParserTest#testGetRequestMissingCRLF}}
> This behavior makes odata2-core incompatible with all implementations of .net 
> OData clients based on {{System.Data.Services.Client}} because it use only 
> one CRLF at the end of request line:
> http://referencesource.microsoft.com/#System.Data.Services.Client/Client/System/Data/Services/Client/DataServiceContext.cs,3277289aacaeb96c
> which results in the following request body:
> {code}
> --batch_86108a65-4dc2-4c0c-bd92-384be755c83a
> Content-Type: application/http
> Content-Transfer-Encoding: binary
> GET https://www.nuget.org/api/v2/Packages HTTP/1.1
> --batch_86108a65-4dc2-4c0c-bd92-384be755c83a--
> {code}
> I see that {{BatchParser}}'s constructor allows to use non strict flag, but 
> at the moment it's impossible to set due to hardcoded value in 
> ProviderFacadeImpl#parseBatchRequest method.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1069) V2: Build 2.0.8 Release

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1069.
-
Resolution: Fixed

Done with commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=adda9d5d611c46f305709503fd6e0212481806f5

> V2: Build 2.0.8 Release
> ---
>
> Key: OLINGO-1069
> URL: https://issues.apache.org/jira/browse/OLINGO-1069
> Project: Olingo
>  Issue Type: Task
>  Components: odata2-core
>Affects Versions: V2 2.0.8
>    Reporter: Christian Amend
>Assignee: Christian Amend
> Fix For: V2 2.0.8
>
>
> Build the release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OLINGO-1069) V2: Build 2.0.8 Release

[Christian Amend (JIRA)]

Christian Amend created OLINGO-1069:
---

 Summary: V2: Build 2.0.8 Release
 Key: OLINGO-1069
 URL: https://issues.apache.org/jira/browse/OLINGO-1069
 Project: Olingo
  Issue Type: Task
  Components: odata2-core
Affects Versions: V2 2.0.8
Reporter: Christian Amend
Assignee: Christian Amend
 Fix For: V2 2.0.8


Build the release.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OLINGO-1064) ComplexType is deserialized as Primitive Type if the value is NULL

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1064:
-

Hi Punith,

I am glad to hear that :)

You can find the source code repository here: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git
Here is a tutorial on how we would prefer the patch file: 
http://olingo.apache.org/contribute.html
If you have questions or want to discuss architecture or implementation 
decisions you can use the comment mechanism here.

There are two ways to solve this IMHO:
1. Make the deserializer EDM aware (My personal favourite but more 
implementation work)
2. hava a post-deserilaization method that checks which properties have been 
deserialized and if they need a different value object in case they are comlex 
or navigation properties.

It would be very helpful to include a test to show that the changes work and to 
prevent future refactorings from breaking the new behavior.

Best Regards,
Christian

> ComplexType is deserialized as Primitive Type if the value is NULL
> --
>
> Key: OLINGO-1064
> URL: https://issues.apache.org/jira/browse/OLINGO-1064
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core, odata4-client, odata4-commons
>Affects Versions: (Java) V4 4.2.0
>Reporter: Punith DG
>Assignee: Christian Amend
> Attachments: complexType.png
>
>
> The ODataClient deserializer wrongly converts the Complex Type field to 
> Primitive Type field if the value received for the complex type is NULL.
> e.g. on querying Person data from OData TripPin service 
> (https://services.odata.org/TripPinRESTierService) I received below JSON 
> response.
> {
>   "@odata.context": 
> "http://services.odata.org/TripPinRESTierService/(S(myhztseklikbg41mbg03ugk5))/$metadata#People(AddressInfo,FavoriteFeature,FirstName,HomeAddress,LastName,UserName)",
>   "value": [{
>   "FavoriteFeature": "Feature1",
>   "FirstName": "Angel",
>   "Gender": "Female",
>   "LastName": "Huffman",
>   "UserName": "angelhuffman",
>   "AddressInfo": [{
>   "Address": "55 Grizzly Peak Rd.",
>   "City": {
>   "Name": "Butte",
>   "CountryRegion": "United States",
>   "Region": "MT"
>   }
>   }],
>   "HomeAddress": null
>   }]
> }
> See that 'HomeAddress' is ComplexType of type 'Location' and received 'null' 
> value.
> Similarly, ComplexType property 'City' is deserialized as Primitive Type in 
> the below response.
> "HomeAddress": {
>   "Address": null,
>   "City": null
>   }
> When you deserialize and get an entity, the HomeAddress property of the 
> Person entity is set to Primitive Type with null value. This could be complex 
> type?
> Metadata URL - http://tinyurl.com/gm8vomc



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OLINGO-1064) ComplexType is deserialized as Primitive Type if the value is NULL

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1064:
-

Hi Punith,

then this seems like a bug to me. I had a short look at the code and it seems 
the only point where the EDM is used is the Binder. So IMHO there is a larger 
issue here.
Unfortunately this is where my client knowledge ends. If you would like to 
contribute some fix for this we would be very grateful. Otherwise you can 
reopen this ticket and hope someone else takes it up. As of now I don`t have 
the time for that.

Best Regards,
Christian

> ComplexType is deserialized as Primitive Type if the value is NULL
> --
>
> Key: OLINGO-1064
> URL: https://issues.apache.org/jira/browse/OLINGO-1064
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core, odata4-client, odata4-commons
>Affects Versions: (Java) V4 4.2.0
>Reporter: Punith DG
>Assignee: Christian Amend
> Attachments: complexType.png
>
>
> The ODataClient deserializer wrongly converts the Complex Type field to 
> Primitive Type field if the value received for the complex type is NULL.
> e.g. on querying Person data from OData TripPin service 
> (https://services.odata.org/TripPinRESTierService) I received below JSON 
> response.
> {
>   "@odata.context": 
> "http://services.odata.org/TripPinRESTierService/(S(myhztseklikbg41mbg03ugk5))/$metadata#People(AddressInfo,FavoriteFeature,FirstName,HomeAddress,LastName,UserName)",
>   "value": [{
>   "FavoriteFeature": "Feature1",
>   "FirstName": "Angel",
>   "Gender": "Female",
>   "LastName": "Huffman",
>   "UserName": "angelhuffman",
>   "AddressInfo": [{
>   "Address": "55 Grizzly Peak Rd.",
>   "City": {
>   "Name": "Butte",
>   "CountryRegion": "United States",
>   "Region": "MT"
>   }
>   }],
>   "HomeAddress": null
>   }]
> }
> See that 'HomeAddress' is ComplexType of type 'Location' and received 'null' 
> value.
> Similarly, ComplexType property 'City' is deserialized as Primitive Type in 
> the below response.
> "HomeAddress": {
>   "Address": null,
>   "City": null
>   }
> When you deserialize and get an entity, the HomeAddress property of the 
> Person entity is set to Primitive Type with null value. This could be complex 
> type?
> Metadata URL - http://tinyurl.com/gm8vomc



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1064) ComplexType is deserialized as Primitive Type if the value is NULL

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1064.
-
Resolution: Information Provided
  Assignee: Christian Amend

Hi Punith,

the ClientDeserializer works without metadata information as the default. This 
means that it can`t decide if a property is a complex property or primitive 
property if the value is null. The same issue appears with expanded navigation 
properties. Currently the parser doesn`t know if it is a navigation propery or 
a complex property when a value is provided because they look exaclty the same 
in the payload. Without further information it is impossible to decide based on 
the payload alone.

In order to work around this you can use the EDM aware client or request "full 
metadata" from the server.

> ComplexType is deserialized as Primitive Type if the value is NULL
> --
>
> Key: OLINGO-1064
> URL: https://issues.apache.org/jira/browse/OLINGO-1064
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core, odata4-client, odata4-commons
>Affects Versions: (Java) V4 4.2.0
>Reporter: Punith DG
>Assignee: Christian Amend
> Attachments: complexType.png
>
>
> The ODataClient deserializer wrongly converts the Complex Type field to 
> Primitive Type field if the value received for the complex type is NULL.
> e.g. on querying Person data from OData TripPin service 
> (https://services.odata.org/TripPinRESTierService) I received below JSON 
> response.
> {
>   "@odata.context": 
> "http://services.odata.org/TripPinRESTierService/(S(myhztseklikbg41mbg03ugk5))/$metadata#People(AddressInfo,FavoriteFeature,FirstName,HomeAddress,LastName,UserName)",
>   "value": [{
>   "FavoriteFeature": "Feature1",
>   "FirstName": "Angel",
>   "Gender": "Female",
>   "LastName": "Huffman",
>   "UserName": "angelhuffman",
>   "AddressInfo": [{
>   "Address": "55 Grizzly Peak Rd.",
>   "City": {
>   "Name": "Butte",
>   "CountryRegion": "United States",
>   "Region": "MT"
>   }
>   }],
>   "HomeAddress": null
>   }]
> }
> See that 'HomeAddress' is ComplexType of type 'Location' and received 'null' 
> value.
> Similarly, ComplexType property 'City' is deserialized as Primitive Type in 
> the below response.
> "HomeAddress": {
>   "Address": null,
>   "City": null
>   }
> When you deserialize and get an entity, the HomeAddress property of the 
> Person entity is set to Primitive Type with null value. This could be complex 
> type?
> Metadata URL - http://tinyurl.com/gm8vomc



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1058) OData V4.0: NextLink Support in streaming to enable server side pagination

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1058.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: (Java) V4 4.4.0

Thanks for the contribution. I have applied it with the following commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=01c6aa1592eeb041556be23253424cc2a04e1627

> OData V4.0: NextLink Support in streaming to enable server side pagination
> --
>
> Key: OLINGO-1058
> URL: https://issues.apache.org/jira/browse/OLINGO-1058
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-commons, odata4-server
>Reporter: Archana Rai
>    Assignee: Christian Amend
> Fix For: (Java) V4 4.4.0
>
> Attachments: streaming.diff
>
>
> There is currently no way to set a next link while streaming an entity 
> collection.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1059) OData V4.0: Cross Service EDM

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1059.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: (Java) V4 4.4.0

Thanks for the contribution. I applied it with the following commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=4b3c02373fa4e237fbefbb0038628c6aef907283

> OData V4.0: Cross Service EDM
> -
>
> Key: OLINGO-1059
> URL: https://issues.apache.org/jira/browse/OLINGO-1059
> Project: Olingo
>  Issue Type: New Feature
>Reporter: Archana Rai
>    Assignee: Christian Amend
> Fix For: (Java) V4 4.4.0
>
> Attachments: crossedm.diff
>
>
> Provide an implementation to enable the Olingo EDM for Cross Service 
> referencing. Cross Service Referencing means that a service developer can 
> extend another metadata document and use types of the other document.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1055) OData V2.0: Omit empty inline tags for null data

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1055.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: V2 2.0.8

Thanks for the contribution. I applied the patch with the following commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=4e1667fcc4ac320aed19e3b0360af4c7fec651f0

> OData V2.0: Omit empty inline tags for null data
> 
>
> Key: OLINGO-1055
> URL: https://issues.apache.org/jira/browse/OLINGO-1055
> Project: Olingo
>  Issue Type: Bug
>Reporter: Archana Rai
>    Assignee: Christian Amend
> Fix For: V2 2.0.8
>
> Attachments: a5d9b86c.diff
>
>
> If a callback is set and there is no inline data we write empty inline tags 
> in XML or a "navigationProperty:null" in JSON.
> To prevent this, we can provide a flag at the EntityProviderWriteProperties 
> to omit the m:inline tag in XML and the navigation property :null in JSON 
> when this flag is set and the callback does not deliver data. 
> If the flag is not set, the default behavior should not be changed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1051) Provide flexible Properties serialization for inline entities

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1051.
-
Resolution: Fixed
  Assignee: Christian Amend

Apllied the patch with the following commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=9142cbd348ca348d92e80ad56980174b5348b7ae

Thanks for the contribution!

> Provide flexible Properties serialization for inline entities
> -
>
> Key: OLINGO-1051
> URL: https://issues.apache.org/jira/browse/OLINGO-1051
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Affects Versions: V2 2.0.6, V2 2.0.7
>Reporter: Ramya
>Assignee: Christian Amend
> Fix For: V2 2.0.8
>
> Attachments: 91e3aa69.diff.zip
>
>
> The current behavior for inline entities uses the 
> EntityProviderWriteProperties to write a list of properties. If these 
> properties are different for every entity of a feed or an inline feed we have 
> no way of providing these dynamic lists. Instead the predefined set from the 
> selectedProperyNames List is used.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OLINGO-1031) ODataResponse and POST, PUT, DELETE

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1031:
-

HI Michele,

unlike HTTP Status Codes the "Error Code" is service specific. Which means that 
if your consumer is aware of the service implementation then yes you can use 
this code to react to it. 

The readErrorDocument() method will give you all information which was in the 
OData Error response so again yes :)

Best Regards,
Chris

> ODataResponse and POST, PUT, DELETE
> ---
>
> Key: OLINGO-1031
> URL: https://issues.apache.org/jira/browse/OLINGO-1031
> Project: Olingo
>  Issue Type: Question
>  Components: odata2-core
>Affects Versions: V2 2.0.1
>Reporter: M Carissimi
>Assignee: Christian Amend
>
> Hello,
> we have an OData 2 service which currently only supports GET requests. We are 
> investigating what is required to extend the service to support POST, PUT and 
> DELETE.
> Looking at your documentation, it appears that we can use the the 
> writeEntry() and writeFeed() methods of the EntityProvider class to perform 
> the required operations. These methods return an ODataResponse. Can we use 
> the ODataResponse to provide error messages to the clients in case the 
> POST/PUT operations can't be completed successfully?
> Delete operations are quite different as clients simply need to use the 
> DELETE method against an entry URL to delete it. In these cases how can we 
> handle error conditions? What error code should we return when an entry can't 
> be deleted and how can we tell the client the reason for the failure?
> Finally, we would like to enforce that client invoking POST, PUT, DELETE 
> operations provide an audit message... How can we achieve this? Do we need to 
> get the clients to POST the audit message first and the reference it in the 
> other operations?
> Thank you for the information



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OLINGO-1031) ODataResponse and POST, PUT, DELETE

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1031:
-

Hi Michele,

you can set the status code at the exception. This is described in the Javadoc: 
https://github.com/apache/olingo-odata2/blob/8b40fff59763818af86a249828784927b8ff8cd2/odata2-lib/odata-api/src/main/java/org/apache/olingo/odata2/api/exception/ODataApplicationException.java

Best Regards,
Christian

> ODataResponse and POST, PUT, DELETE
> ---
>
> Key: OLINGO-1031
> URL: https://issues.apache.org/jira/browse/OLINGO-1031
> Project: Olingo
>  Issue Type: Question
>  Components: odata2-core
>Affects Versions: V2 2.0.1
>Reporter: M Carissimi
>Assignee: Christian Amend
>
> Hello,
> we have an OData 2 service which currently only supports GET requests. We are 
> investigating what is required to extend the service to support POST, PUT and 
> DELETE.
> Looking at your documentation, it appears that we can use the the 
> writeEntry() and writeFeed() methods of the EntityProvider class to perform 
> the required operations. These methods return an ODataResponse. Can we use 
> the ODataResponse to provide error messages to the clients in case the 
> POST/PUT operations can't be completed successfully?
> Delete operations are quite different as clients simply need to use the 
> DELETE method against an entry URL to delete it. In these cases how can we 
> handle error conditions? What error code should we return when an entry can't 
> be deleted and how can we tell the client the reason for the failure?
> Finally, we would like to enforce that client invoking POST, PUT, DELETE 
> operations provide an audit message... How can we achieve this? Do we need to 
> get the clients to POST the audit message first and the reference it in the 
> other operations?
> Thank you for the information



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (OLINGO-1031) ODataResponse and POST, PUT, DELETE

[Christian Amend (JIRA)]

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

Christian Amend edited comment on OLINGO-1031 at 11/16/16 10:31 AM:


As you said you can use the write... methods to create the payload. Here is the 
turorial: 
http://olingo.apache.org/doc/odata2/tutorials/Olingo_Tutorial_BasicWrite.html

If you want the provide error messages you can use the ODataApplication 
exception. Just throw this in your code and the Olingo library will do the 
rest. You can throw those exceptions anywhere in your processor. This includes 
the DELETE case.

As for the audit messages you could use a custom header field to achieve this.

Best Regards,
Chris


was (Author: chrisam):
As you said you can use the write... methods to create the payload. Here is the 
turorial: 
http://olingo.apache.org/doc/odata2/tutorials/Olingo_Tutorial_BasicWrite.html

If you want the provide error messages you can use the ODataApplication 
exception. Just throw this in your code and the Olingo library will do the rest.

As for the audit messages you could use a custom header field to achieve this.

Best Regards,
Chris

> ODataResponse and POST, PUT, DELETE
> ---
>
> Key: OLINGO-1031
> URL: https://issues.apache.org/jira/browse/OLINGO-1031
> Project: Olingo
>  Issue Type: Question
>  Components: odata2-core
>Affects Versions: V2 2.0.1
>Reporter: M Carissimi
>Assignee: Christian Amend
>
> Hello,
> we have an OData 2 service which currently only supports GET requests. We are 
> investigating what is required to extend the service to support POST, PUT and 
> DELETE.
> Looking at your documentation, it appears that we can use the the 
> writeEntry() and writeFeed() methods of the EntityProvider class to perform 
> the required operations. These methods return an ODataResponse. Can we use 
> the ODataResponse to provide error messages to the clients in case the 
> POST/PUT operations can't be completed successfully?
> Delete operations are quite different as clients simply need to use the 
> DELETE method against an entry URL to delete it. In these cases how can we 
> handle error conditions? What error code should we return when an entry can't 
> be deleted and how can we tell the client the reason for the failure?
> Finally, we would like to enforce that client invoking POST, PUT, DELETE 
> operations provide an audit message... How can we achieve this? Do we need to 
> get the clients to POST the audit message first and the reference it in the 
> other operations?
> Thank you for the information



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1031) ODataResponse and POST, PUT, DELETE

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1031.
-
Resolution: Information Provided
  Assignee: Christian Amend

As you said you can use the write... methods to create the payload. Here is the 
turorial: 
http://olingo.apache.org/doc/odata2/tutorials/Olingo_Tutorial_BasicWrite.html

If you want the provide error messages you can use the ODataApplication 
exception. Just throw this in your code and the Olingo library will do the rest.

As for the audit messages you could use a custom header field to achieve this.

Best Regards,
Chris

> ODataResponse and POST, PUT, DELETE
> ---
>
> Key: OLINGO-1031
> URL: https://issues.apache.org/jira/browse/OLINGO-1031
> Project: Olingo
>  Issue Type: Question
>  Components: odata2-core
>Affects Versions: V2 2.0.1
>Reporter: M Carissimi
>Assignee: Christian Amend
>
> Hello,
> we have an OData 2 service which currently only supports GET requests. We are 
> investigating what is required to extend the service to support POST, PUT and 
> DELETE.
> Looking at your documentation, it appears that we can use the the 
> writeEntry() and writeFeed() methods of the EntityProvider class to perform 
> the required operations. These methods return an ODataResponse. Can we use 
> the ODataResponse to provide error messages to the clients in case the 
> POST/PUT operations can't be completed successfully?
> Delete operations are quite different as clients simply need to use the 
> DELETE method against an entry URL to delete it. In these cases how can we 
> handle error conditions? What error code should we return when an entry can't 
> be deleted and how can we tell the client the reason for the failure?
> Finally, we would like to enforce that client invoking POST, PUT, DELETE 
> operations provide an audit message... How can we achieve this? Do we need to 
> get the clients to POST the audit message first and the reference it in the 
> other operations?
> Thank you for the information



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OLINGO-1046) Whitespaces in functions not allowed

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-1046:
-

I don`t think so. The ABNF clearly states "BWS" which means bad whitespace. We 
are actually specification conform with this. The question is rather if we 
should be more relaxed.

> Whitespaces in functions not allowed
> 
>
> Key: OLINGO-1046
> URL: https://issues.apache.org/jira/browse/OLINGO-1046
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-server
>Affects Versions: (Java) V4 4.3.0
>Reporter: Frederik Zimmer
>
> Whitespaces before/after comma/parenthesis in functions are allowed by the 
> ABNF but Olingo is unable to parse them.
> This would result in an error (inserted space after comma in Testcase of 
> TestFullResourcePath):
> startswith(PropertyCompAllPrim/PropertyString, 'Wall')
> ABNF example:
> startsWithMethodCallExpr = 'startswith' OPEN BWS commonExpr BWS COMMA BWS 
> commonExpr BWS CLOSE
> BWS =  *( SP / HTAB / "%20" / "%09" )  ; "bad" whitespace



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1047) Edmx validation for multi level entity type inheritance

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1047.
-
   Resolution: Fixed
 Assignee: Christian Amend
Fix Version/s: V2 2.0.8

Thanks for the contribution. I have applied it with the following commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=a823475b5f13a996bd41dccd38411a73d69bf138

> Edmx validation for multi level entity type inheritance
> ---
>
> Key: OLINGO-1047
> URL: https://issues.apache.org/jira/browse/OLINGO-1047
> Project: Olingo
>  Issue Type: Bug
>  Components: odata2-core
>Reporter: Archana Rai
>    Assignee: Christian Amend
> Fix For: V2 2.0.8
>
> Attachments: diff.patch
>
>
> The current behavior for edmx validation where an Entity type has a base 
> entity type is handled for 1 level only.
> For Entity type which has multiple level of base types and if the direct base 
> type does not have key an error is thrown.
> e.g. if entity type StringDataConfigParameter has base type 
> DataConfigParameter and DataConfigParameter has base type ConfigParameter and 
> ConfigParameter has a key but DataConfigParameter does not have a key then 
> while validating StringDataConfigParameter only DataConfigParameter is 
> checked for the key and if key is not there error is thrown.
> Such scenarios should also be validated till the last entity base type.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OLINGO-1037) V4: Support Geotypes on server in JSON

[Christian Amend (JIRA)]

Christian Amend created OLINGO-1037:
---

 Summary: V4: Support Geotypes on server in JSON
 Key: OLINGO-1037
 URL: https://issues.apache.org/jira/browse/OLINGO-1037
 Project: Olingo
  Issue Type: New Feature
  Components: odata4-server
Affects Versions: (Java) V4 4.3.0
Reporter: Christian Amend
Assignee: Christian Amend
 Fix For: (Java) V4 4.4.0


Support GeoTypes in the serializer and deserializer for the json format



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1033) V4: @odata.type annotation incorrect for primitive types

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1033.
-
Resolution: Fixed

Fixed with commit: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=5255c336ebde38493337bd6761b49a80654a3289

> V4: @odata.type annotation incorrect for primitive types
> 
>
> Key: OLINGO-1033
> URL: https://issues.apache.org/jira/browse/OLINGO-1033
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-client, odata4-server
>Affects Versions: (Java) V4 4.2.0, (Java) V4 4.3.0
>    Reporter: Christian Amend
>Assignee: Christian Amend
> Fix For: (Java) V4 4.4.0
>
>
> The @odata.type annotation is incorrecty serialized for primitive types. the 
> current behavior has this output: ...@odata.type":"Int32" but should look 
> like this: ...@odata.type":"#Int32"
> Here the specfication part: 
> 4.5.3 Annotation odata.type
> The odata.type annotation specifies the type of a JSON object or name/value 
> pair. Its value is a URI that identifies the type of the property or object. 
> For built-in primitive types the value is the unqualified name of the 
> primitive type, specified as a URI fragment.
> Example:
> {
>   "@odata.context": "http://host/service/$metadata#Customers/$entity;,
>   "@odata.type": "#Model.VipCustomer",
> "ID": 2,
> "DynamicLimit": "INF",
> "dynamicli...@odata.type": "#Double",
> ...
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (OLINGO-1033) V4: @odata.type annotation incorrect for primitive types

[Christian Amend (JIRA)]

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

Christian Amend reassigned OLINGO-1033:
---

Assignee: Christian Amend

> V4: @odata.type annotation incorrect for primitive types
> 
>
> Key: OLINGO-1033
> URL: https://issues.apache.org/jira/browse/OLINGO-1033
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-client, odata4-server
>Affects Versions: (Java) V4 4.2.0, (Java) V4 4.3.0
>    Reporter: Christian Amend
>Assignee: Christian Amend
> Fix For: (Java) V4 4.4.0
>
>
> The @odata.type annotation is incorrecty serialized for primitive types. the 
> current behavior has this output: ...@odata.type":"Int32" but should look 
> like this: ...@odata.type":"#Int32"
> Here the specfication part: 
> 4.5.3 Annotation odata.type
> The odata.type annotation specifies the type of a JSON object or name/value 
> pair. Its value is a URI that identifies the type of the property or object. 
> For built-in primitive types the value is the unqualified name of the 
> primitive type, specified as a URI fragment.
> Example:
> {
>   "@odata.context": "http://host/service/$metadata#Customers/$entity;,
>   "@odata.type": "#Model.VipCustomer",
> "ID": 2,
> "DynamicLimit": "INF",
> "dynamicli...@odata.type": "#Double",
> ...
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (OLINGO-1036) V4: DefaultDebugSupport enhancement

[Christian Amend (JIRA)]

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

Christian Amend closed OLINGO-1036.
---
   Resolution: Won't Fix
Fix Version/s: (was: (Java) V4 4.4.0)

The description of the class explicitly states that if registered a debug 
output will always be given. So this issue is obsolete.

> V4: DefaultDebugSupport enhancement
> ---
>
> Key: OLINGO-1036
> URL: https://issues.apache.org/jira/browse/OLINGO-1036
> Project: Olingo
>  Issue Type: Bug
>  Components: odata4-server
>Affects Versions: (Java) V4 4.3.0
>    Reporter: Christian Amend
>Assignee: Christian Amend
>
> Currently the DefaultDebugSupport returns true for every user by default if 
> checking when a user is authorized to see the debug support. This should be  
> set to false.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OLINGO-1033) V4: @odata.type annotation incorrect for primitive types

[Christian Amend (JIRA)]

Christian Amend created OLINGO-1033:
---

 Summary: V4: @odata.type annotation incorrect for primitive types
 Key: OLINGO-1033
 URL: https://issues.apache.org/jira/browse/OLINGO-1033
 Project: Olingo
  Issue Type: Bug
  Components: odata4-client, odata4-server
Affects Versions: (Java) V4 4.3.0, (Java) V4 4.2.0
Reporter: Christian Amend
 Fix For: (Java) V4 4.4.0


The @odata.type annotation is incorrecty serialized for primitive types. the 
current behavior has this output: ...@odata.type":"Int32" but should look like 
this: ...@odata.type":"#Int32"

Here the specfication part: 
4.5.3 Annotation odata.type
The odata.type annotation specifies the type of a JSON object or name/value 
pair. Its value is a URI that identifies the type of the property or object. 
For built-in primitive types the value is the unqualified name of the primitive 
type, specified as a URI fragment.
Example:
{
  "@odata.context": "http://host/service/$metadata#Customers/$entity;,
  "@odata.type": "#Model.VipCustomer",
"ID": 2,
"DynamicLimit": "INF",
"dynamicli...@odata.type": "#Double",
...
}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1028) V4: $filter statements on navigation properties

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1028.
-
Resolution: Fixed

Fixed with: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata4.git;a=commit;h=72fcaa1a54a3607ee2b94f66414677ab6f9c8e92

> V4: $filter statements on navigation properties
> ---
>
> Key: OLINGO-1028
> URL: https://issues.apache.org/jira/browse/OLINGO-1028
> Project: Olingo
>  Issue Type: Improvement
>Affects Versions: (Java) V4 4.3.0
>    Reporter: Christian Amend
>    Assignee: Christian Amend
> Fix For: (Java) V4 4.4.0
>
>
> Fix multiplicity handling in V4 filter statements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OLINGO-1028) V4: $filter statements on navigation properties

[Christian Amend (JIRA)]

Christian Amend created OLINGO-1028:
---

 Summary: V4: $filter statements on navigation properties
 Key: OLINGO-1028
 URL: https://issues.apache.org/jira/browse/OLINGO-1028
 Project: Olingo
  Issue Type: Improvement
Affects Versions: (Java) V4 4.3.0
Reporter: Christian Amend
Assignee: Christian Amend
 Fix For: (Java) V4 4.4.0


Fix multiplicity handling in V4 filter statements.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OLINGO-549) POC: ODataV4 JPA Processor

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-549:


[~jemag] I don`t know how this develops and how the implementation will take 
place at this point in time. I have started a discussion on the dev mailing 
list (dev@olingo.apache.org) on how to best integrate the code into Olingo. If 
you like you can subscribe to this list (dev-subscr...@olingo.apache.org) and 
take part in this discussion.

My very personal opinion is that you should not expect a stable JPA release 
within this or next month. I think that it would be best to make an alpha 
release first to see how the code behaves and if there is interest from the 
community e.g. other contributors. I personally will invest time to integrate 
this into the project, setting up releases or guiding discussion regarding 
OData questions. I don`t think I will have time to actually implement features 
or bug fixes for the JPA extension. If you would like to get involved here you 
could make certain that the project is going into the right direction :)

> POC: ODataV4 JPA Processor
> --
>
> Key: OLINGO-549
> URL: https://issues.apache.org/jira/browse/OLINGO-549
> Project: Olingo
>  Issue Type: New Feature
>  Components: odata4-JPA
>Affects Versions: (JPA) V4 4.0.0-beta-01
>Reporter: Chandan V.A
>
> A proof of Concept for transforming JPA models into OData V4 compliant EDM 
> models and supporting OData V4 protocol compliant operations into JPA 2.0/2.1 
> specific operations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (OLINGO-1026) V2: filter should accept NavigationProperty eq null

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1026.
-
Resolution: Fixed

Resolved with: 
https://git-wip-us.apache.org/repos/asf?p=olingo-odata2.git;a=commit;h=919d4ac0f85f59295f7fde00a9f8cdc12085e441

> V2: filter should accept NavigationProperty eq null
> ---
>
> Key: OLINGO-1026
> URL: https://issues.apache.org/jira/browse/OLINGO-1026
> Project: Olingo
>  Issue Type: Improvement
>  Components: odata2-core
>Affects Versions: V2 2.0.7
>    Reporter: Christian Amend
>Assignee: Christian Amend
> Fix For: V2 2.0.8
>
>
> Filter should accept NavigationProperty eq null to filter for entities which 
> have no navigation assigned. NavigationProperty eq ,some simple type value. 
> should be blocked as before.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (OLINGO-1026) V2: filter should accept NavigationProperty eq null

[Christian Amend (JIRA)]

Christian Amend created OLINGO-1026:
---

 Summary: V2: filter should accept NavigationProperty eq null
 Key: OLINGO-1026
 URL: https://issues.apache.org/jira/browse/OLINGO-1026
 Project: Olingo
  Issue Type: Improvement
  Components: odata2-core
Affects Versions: V2 2.0.7
Reporter: Christian Amend
Assignee: Christian Amend
 Fix For: V2 2.0.8


Filter should accept NavigationProperty eq null to filter for entities which 
have no navigation assigned. NavigationProperty eq ,some simple type value. 
should be blocked as before.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (OLINGO-1023) V4: Build 4.3.0 release

[Christian Amend (JIRA)]

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

Christian Amend closed OLINGO-1023.
---
Resolution: Fixed

Done

> V4: Build 4.3.0 release
> ---
>
> Key: OLINGO-1023
> URL: https://issues.apache.org/jira/browse/OLINGO-1023
> Project: Olingo
>  Issue Type: Task
>    Reporter: Christian Amend
>    Assignee: Christian Amend
>
> - Build release candidate
> - Build release after vote
> - Update Downloadpage and JavDoc
> - Send Announce Mail



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (OLINGO-549) POC: ODataV4 JPA Processor

[Christian Amend (JIRA)]

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

Christian Amend commented on OLINGO-549:


[~jemag] there has been another contribution with this JIRA issue: 
https://issues.apache.org/jira/browse/OLINGO-1010
Apparently it is a first working JPA solution. I intended to look at it this 
week and see how we can integrate it into Olingo.

If you have any feedback regarding the contribution please let us know. My JPA 
knowledge is not the best :)

> POC: ODataV4 JPA Processor
> --
>
> Key: OLINGO-549
> URL: https://issues.apache.org/jira/browse/OLINGO-549
> Project: Olingo
>  Issue Type: New Feature
>  Components: odata4-JPA
>Affects Versions: (JPA) V4 4.0.0-beta-01
>Reporter: Chandan V.A
>
> A proof of Concept for transforming JPA models into OData V4 compliant EDM 
> models and supporting OData V4 protocol compliant operations into JPA 2.0/2.1 
> specific operations.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[ANNOUNCE] Apache Olingo 4.3.0 has been released

[Christian Amend]

Hello,

we proudly announce that Apache Olingo 4.3.0 has been released.
This is the fourth stable Olingo release for OData Version 4
(see specification [1] and new features [2]).

This release is available for download:
http://olingo.apache.org/doc/odata4/download.html

Tutorials and documentation are also available:
http://olingo.apache.org/doc/odata4/index.html

Available also in central maven repository:
http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.apache.olingo%22%20AND%20v%3A%224.3.0%22
and the Apache repository:
https://repository.apache.org/index.html#nexus-search;gav~org.apache.olingo~~4.3.0~~

If you would like to get involved please write to: u...@olingo.apache.org
Or subscribe to our mailing list as described here:
http://olingo.apache.org/support.html

Apache Olingo is a Java library which enables developers to
implement OData service providers (server) and consumers (clients)
for OData V2 and V4.

The Open Data Protocol (OData, http://www.odata.org/) is an open protocol
to allow the creation and consumption of queryable and interoperable
RESTful APIs in a simple and standard way.

[1]: http://docs.oasis-open.org/odata/odata/v4.0/odata-v4.0-part1-protocol.html
[2]: 
http://docs.oasis-open.org/odata/new-in-odata/v4.0/cn01/new-in-odata-v4.0-cn01.html

Release Notes - Olingo - Version 4.3.0
---
Link: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314520=12335441

Bug
[OLINGO-931] - $select does not work with JsonSerializer
[OLINGO-939] - Content-Type wrong in error response in server-core-ext module
[OLINGO-960] - Failure to find as Alias shound not throw an exception
[OLINGO-964] - Cast type (typeFilterOnCollection) not taken into
account while expanding a collection
[OLINGO-966] - Parse of filter with guild parameter fails
[OLINGO-967] - batch request rollback is not working properly
[OLINGO-977] - Missing call "writer.writeStartDocument" in
ODataXmlSerializer.complexCollection()
[OLINGO-980] - INVALID_NULL_ANNOTATION when update navigation property to null
[OLINGO-981] - Binding operation null on to one
[OLINGO-982] - Metadataparser does not set correct value for Nullable
attriibute of Navigation Property
[OLINGO-984] - Client-Proxy: collection of enums as property not supported
[OLINGO-987] - V4: Serializer can´t resolve ESCompCollComp?$format=json
[OLINGO-988] - V4: ExpandOption created by the deserializer contains
duplicates in deep instert cases
[OLINGO-991] - OData4HttpHandler does not honor split while processing request
[OLINGO-1002] - EDMParameter type is missing from TargetType
[OLINGO-1003] - Binary content in batch requests gets corrupted
[OLINGO-1015] - Wrong batch content header handling

Improvement
[OLINGO-567] - Support odata.metadata=full on server side serialization
[OLINGO-936] - V4 code cleanup epic
[OLINGO-954] - Send OData Version Header with every Response to be
more specification compliant
[OLINGO-979] - V4: Make ODataApplicationException translatable
[OLINGO-989] - V4: Minor Client enhancements
[OLINGO-990] - V4: Allow custom Headers for metadata requests
[OLINGO-1004] - V4: Clean Up FIT module

New Feature
[OLINGO-935] - V4 $apply support
[OLINGO-995] - V4: Support Http HEAD method
[OLINGO-1009] - Provide serilization support for $levels with $expand

Task
[OLINGO-993] - V4: Provide a beta release via the maven nexus
[OLINGO-997] - Make release build work with Java 8


Best Regards,
Christian

[jira] [Resolved] (OLINGO-1004) V4: Clean Up FIT module

[Christian Amend (JIRA)]

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

Christian Amend resolved OLINGO-1004.
-
Resolution: Fixed

Resolved for this release. For later releases we will have another issue.

> V4: Clean Up FIT module
> ---
>
> Key: OLINGO-1004
> URL: https://issues.apache.org/jira/browse/OLINGO-1004
> Project: Olingo
>  Issue Type: Improvement
>Affects Versions: (Java) V4 4.2.0
>    Reporter: Christian Amend
>    Assignee: Christian Amend
> Fix For: (Java) V4 4.3.0
>
> Attachments: 0001-refactored-conformance-tests.patch, 
> 0001-removed-CTCompCompExtended-and-added-CTBase-in-ESFourKeyAlias.patch, 
> 0001-removed-ErrorResponseTestITCase.patch, 0002-edm-clean-up.patch, 
> 0002-renamed-BoundOpearionITCase-to-BoundOper.patch, 
> 0003-edited-edm-for-consistency.patch, 
> 0003-refactored-some-JSON-conformance-tests.patch, 
> moved-some-Metadata-Tests.patch
>
>
> Clean up duplicate tests and use the server module where possible.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)