[jira] [Created] (OLINGO-1114) NULL value change the type when convert ClientEntity to a HttpEntity
Jin ZHAO created OLINGO-1114:
Summary: NULL value change the type when convert ClientEntity to a
HttpEntity
Key: OLINGO-1114
URL: https://issues.apache.org/jira/browse/OLINGO-1114
Project: Olingo
Issue Type: Bug
Affects Versions: (Java) V4 4.3.0
Reporter: Jin ZHAO
Priority: Critical
Attachments: result_compare.png, TestEntityConvert.java
Please see my attached test code:
ClientEntity add a property "revenue" with null value. and type is "Decimal"
But when convert to HttpClient type. the type change to "String"
When I use this for Microsoft CRM create entity, I got this kind of error
message.
{code}
{
"error":{
"code":"","message":"A value was encountered that has a type name that is
incompatible with the metadata. The value specified its type as 'Edm.String',
but the type specified in the metadata is 'Edm.Decimal'.","innererror":{
"message":"A value was encountered that has a type name that is
incompatible with the metadata. The value specified its type as 'Edm.String',
but the type specified in the metadata is
'Edm.Decimal'.","type":"Microsoft.Crm.CrmHttpException","stacktrace":" at
Microsoft.Crm.Extensibility.OData.CrmODataUtilities.ValidateInputParameters(ModelStateDictionary
controllerModelState)\r\n at
Microsoft.Crm.Extensibility.OData.EntityController.PostEntitySet(String
entitySetName, EdmEntityObject entityObject)\r\n at lambda_method(Closure ,
Object , Object[] )\r\n at
System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>c__DisplayClass10.b__9(Object
instance, Object[] methodParameters)\r\n at
System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.Execute(Object
instance, Object[] arguments)\r\n at
System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext
controllerContext, IDictionary`2 arguments, CancellationToken
cancellationToken)\r\n--- End of stack trace from previous location where
exception was thrown ---\r\n at
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
task)\r\n at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n
at
System.Web.Http.Controllers.ApiControllerActionInvoker.d__0.MoveNext()\r\n---
End of stack trace from previous location where exception was thrown ---\r\n
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
task)\r\n at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n
at
System.Web.Http.Controllers.ActionFilterResult.d__2.MoveNext()\r\n---
End of stack trace from previous location where exception was thrown ---\r\n
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()\r\n at
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
task)\r\n at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()\r\n
at
System.Web.Http.Dispatcher.HttpControllerDispatcher.d__1.MoveNext()"
}
}
}
{code}
*So the type of null value property should not be changed!*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (OLINGO-1046) Whitespaces in functions not allowed
[ https://issues.apache.org/jira/browse/OLINGO-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramesh Reddy resolved OLINGO-1046. -- Resolution: Fixed Fix Version/s: (Java) V4 4.4.0 Thank you [~chrisam] for the review. Committed with https://github.com/apache/olingo-odata4/commit/4a51d16425144a7de0be0f9dcd01c667bed322df > 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 > Fix For: (Java) V4 4.4.0 > > > 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
[ https://issues.apache.org/jira/browse/OLINGO-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/OLINGO-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (OLINGO-1046) Whitespaces in functions not allowed
[ https://issues.apache.org/jira/browse/OLINGO-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986538#comment-15986538 ] Ramesh Reddy commented on OLINGO-1046: -- [~chrisam] Can you review this patch? Taking a look at ABNF while review helps where the BWS is allowed. > 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-1062) Cannot consume Odata Reference Services with Annotations
[
https://issues.apache.org/jira/browse/OLINGO-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986441#comment-15986441
]
Ralf Handl commented on OLINGO-1062:
[~rareddy] no, there's no implicit reference/knowledge about the core
vocabularies.
On the other hand we strongly encourage implementations to follow [Postel's
Law|https://en.wikipedia.org/wiki/Robustness_principle] and "be liberal in what
you accept from others", so the client library REALLY SHOULD pass the
annotation on to the calling application and work as if the term namespace had
been included from a /dev/null URL without an alias.
Note: URIs in edmx:Reference elements don't have to be dereferenceable, so a
document with
is perfectly legal. As the library can't rely on dereferencing the Uri and thus
checking whether the term Unknown.Schema.SomeTerm is actually defined there, it
can just work as if it had found such a placeholder edmx:Reference, and only
fail if the client application asks for e.g. Uri attribute value.
> Cannot consume Odata Reference Services with Annotations
>
>
> Key: OLINGO-1062
> URL: https://issues.apache.org/jira/browse/OLINGO-1062
> Project: Olingo
> Issue Type: Bug
> Components: odata4-client
>Affects Versions: (Java) V4 4.3.0
>Reporter: Lars Laegner
>
> The http://services.odata.org/TripPinRESTierService/ service returns the
> following annotation:
> ...
> EntityType="Microsoft.OData.Service.Sample.TrippinInMemory.Models.Airline">
>
> Name...
> unfortunately, the used Org.OData.Core.V1 namespace is not referencing
> anywhere an alias or namespace in the schema.
> This results, when retrieving the code with the latest available OData V4 Lib
> for Java, in the EdmAnnotationClass Code
> public EdmTerm getTerm() {
> if (term == null) {
> if (annotation.getTerm() == null) { throw new EdmException("Term must not be
> null for an annotation."); }
> term = edm.getTerm(new FullQualifiedName(annotation.getTerm()));
> }
> return term; }
> that in debugging the
> annotation.getTerm()=="Org.OData.Core.V1.OptimisticConcurrency" but the term
> is then set to null from edm.getTerm() as it seems to check for available
> namespace/aliases in the schema and cannot find one.
> So practically, this annotation does not exist for the currently latest
> Olingo-OData-Client-for-Java-4.3.0
> The same for
> http://services.odata.org/V4/(S(tauqx0n1pg4nytucatnssdwb))/TripPinServiceRW/
> I have cross created this issue in
> https://github.com/OData/odataorg.github.io/issues/117 as i am not sure,
> wether the service is not correct or the client should be more forgiving
--
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
[ 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
[ 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
[ 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
[
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] [Commented] (OLINGO-753) URIUtils.buildFunctionInvokeURI() build a wrong uri when the uri parameter contains /$count
[ https://issues.apache.org/jira/browse/OLINGO-753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15986332#comment-15986332 ] Ramya commented on OLINGO-753: -- Hi, The URIUtils class is modified to handle query options like /$count, /$value, /$ref. Also, the class is modified to handle cases when a functionName is followed by a navigation segment. Please find the patch file attached. Kindly test the fix and get back if the issue still exists. Regards, Ramya > 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 > 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] [Updated] (OLINGO-753) URIUtils.buildFunctionInvokeURI() build a wrong uri when the uri parameter contains /$count
[ https://issues.apache.org/jira/browse/OLINGO-753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramya updated OLINGO-753: - Attachment: OLINGO-753.diff > 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 > 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] [Updated] (OLINGO-1099) Refactor the V4 $levels implementation
[ https://issues.apache.org/jira/browse/OLINGO-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Archana Rai updated OLINGO-1099: Attachment: f7aa6aac.diff > 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 >Priority: Minor > 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] [Updated] (OLINGO-1099) Refactor the V4 $levels implementation
[ https://issues.apache.org/jira/browse/OLINGO-1099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Archana Rai updated OLINGO-1099: Attachment: (was: $level.diff) > 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 >Priority: Minor > 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] [Updated] (OLINGO-975) Olingo client sends incorrect types for collection members
[
https://issues.apache.org/jira/browse/OLINGO-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramya updated OLINGO-975:
-
Attachment: OLINGO975.diff
> 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
> 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] [Updated] (OLINGO-975) Olingo client sends incorrect types for collection members
[
https://issues.apache.org/jira/browse/OLINGO-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ramya updated OLINGO-975:
-
Attachment: (was: OLINGO-975.diff)
> 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
>
> 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)
