[jira] [Commented] (OLINGO-1166) Annotations for members of Enum types in the CSDL appear as siblings instead of as children
[
https://issues.apache.org/jira/browse/OLINGO-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130890#comment-16130890
]
Tom van Wietmarschen commented on OLINGO-1166:
--
You mean like a regression test or just a simple testcase that demonstrates the
issue ? As in: what should the test demonstrate/test for? Are there any
published guidelines/requirements for such tests ?
> 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
> Attachments:
> 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] [Commented] (OLINGO-1166) Annotations for members of Enum types in the CSDL appear as siblings instead of as children
[
https://issues.apache.org/jira/browse/OLINGO-1166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130844#comment-16130844
]
Ramesh Reddy commented on OLINGO-1166:
--
[~Aaargh!] If can add a test case that would be good for the quick patch
acceptance.
> 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
> Attachments:
> 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] [Updated] (OLINGO-1168) Unable to customize Edm.DateTime serialization
[ https://issues.apache.org/jira/browse/OLINGO-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Tretyakov updated OLINGO-1168: - Summary: Unable to customize Edm.DateTime serialization (was: Unable to customize Edm.DateTime setializtion) > Unable to customize Edm.DateTime serialization > -- > > Key: OLINGO-1168 > URL: https://issues.apache.org/jira/browse/OLINGO-1168 > Project: Olingo > Issue Type: Bug > Components: odata2-core >Affects Versions: V2 2.0.9 >Reporter: Dmitry Tretyakov > Fix For: V2 2.0.10 > > > Edm.DateTime serializer does not use timezones while value serialization > (OLINGO-430) and it blocks some OData feed consumers which rely on timezone: > [TW-51224|https://youtrack.jetbrains.com/issue/TW-51224] > Currently there is no way to set custom serializer for Edm types since in > library code they are deeply hard coded. > How we could work around this limitation? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OLINGO-1168) Unable to customize Edm.DateTime setializtion
[ https://issues.apache.org/jira/browse/OLINGO-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Tretyakov updated OLINGO-1168: - Description: Edm.DateTime serializer does not use timezones while value serialization (OLINGO-430) and it blocks some OData feed consumers which rely on timezone: [TW-51224|https://youtrack.jetbrains.com/issue/TW-51224] Currently there is no way to set custom serializer for Edm types since in library code they are deeply hard coded. How we could work around this limitation? was: Edm.DateTime serializer does not use timezones while value serialization (OLINGO-430) and it blocks some OData feed consumers which rely on timezone: [TW-51224](https://youtrack.jetbrains.com/issue/TW-51224) Currently there is no way to set custom serializer for Edm types since in library code they are deeply hard coded. How we could work around this limitation? > Unable to customize Edm.DateTime setializtion > - > > Key: OLINGO-1168 > URL: https://issues.apache.org/jira/browse/OLINGO-1168 > Project: Olingo > Issue Type: Bug > Components: odata2-core >Affects Versions: V2 2.0.9 >Reporter: Dmitry Tretyakov > Fix For: V2 2.0.10 > > > Edm.DateTime serializer does not use timezones while value serialization > (OLINGO-430) and it blocks some OData feed consumers which rely on timezone: > [TW-51224|https://youtrack.jetbrains.com/issue/TW-51224] > Currently there is no way to set custom serializer for Edm types since in > library code they are deeply hard coded. > How we could work around this limitation? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OLINGO-1167) Pojogen fails when resource has same name as primitive type
[
https://issues.apache.org/jira/browse/OLINGO-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Ammer updated OLINGO-1167:
Description:
At some parts Olingo does not use the fully qualified name of a resource to
reference it.Therefore _pojogen_ fails when you have a resource with the same
name as a value defined in
[EdmPrimitiveTypeKind.java|https://github.com/apache/olingo-odata4/blob/6bc17b668c16bbf96458c996bb9d9a768c74dc98/lib/commons-api/src/main/java/org/apache/olingo/commons/api/edm/EdmPrimitiveTypeKind.java].
Take the following scenario:
*$metadata*
{code:xml}
...
...
{code}
My {{self.edu.Binary}} resource match with the primitive kind {{Edm.Binary}}
due to the check in
[EdmTypeInfo.java|https://github.com/apache/olingo-odata4/blob/4a51d16425144a7de0be0f9dcd01c667bed322df/lib/commons-core/src/main/java/org/apache/olingo/commons/core/edm/EdmTypeInfo.java#L107]:
{code:java}this.primitiveType =
EdmPrimitiveTypeKind.valueOf(this.fullQualifiedName.getName());{code}
When the code generator tries to access the type of the entity it throws a
NullPointerException.
was:
At some parts Olingo does not use the fully qualified name of a resource to
reference it.Therefore _pojogen_ fails when you have a resource with the same
name as a value defined in
[EdmPrimitiveTypeKind.java|https://github.com/apache/olingo-odata4/blob/6bc17b668c16bbf96458c996bb9d9a768c74dc98/lib/commons-api/src/main/java/org/apache/olingo/commons/api/edm/EdmPrimitiveTypeKind.java].
Take the following scenario:
*$metadata*
{code:xml}
...
...
{code}
My {{self.edu.Binary}} resource match with the primitive kind {{Edm.Binary}}
due to the check in
[EdmTypeInfo.java|https://github.com/apache/olingo-odata4/blob/4a51d16425144a7de0be0f9dcd01c667bed322df/lib/commons-core/src/main/java/org/apache/olingo/commons/core/edm/EdmTypeInfo.java#L107]:
{code:java}this.primitiveType =
EdmPrimitiveTypeKind.valueOf(this.fullQualifiedName.getName());{code}
When the code generator tries to access the type of the entity which would not
been done for primitives it throws a NullPointerException.
> Pojogen fails when resource has same name as primitive type
> ---
>
> Key: OLINGO-1167
> URL: https://issues.apache.org/jira/browse/OLINGO-1167
> Project: Olingo
> Issue Type: Bug
> Components: odata4-commons, odata4-ext
>Affects Versions: (Java) V4 4.2.0, (Java) V4 4.3.0
> Environment: EntityType with same name as EdmPrimitiveTypeKind. For
> instance: Binary
>Reporter: Simon Ammer
>Priority: Critical
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> At some parts Olingo does not use the fully qualified name of a resource to
> reference it.Therefore _pojogen_ fails when you have a resource with the same
> name as a value defined in
> [EdmPrimitiveTypeKind.java|https://github.com/apache/olingo-odata4/blob/6bc17b668c16bbf96458c996bb9d9a768c74dc98/lib/commons-api/src/main/java/org/apache/olingo/commons/api/edm/EdmPrimitiveTypeKind.java].
> Take the following scenario:
> *$metadata*
> {code:xml}
> ...
>
>
>
>
>
>
> ...
> {code}
> My {{self.edu.Binary}} resource match with the primitive kind {{Edm.Binary}}
> due to the check in
> [EdmTypeInfo.java|https://github.com/apache/olingo-odata4/blob/4a51d16425144a7de0be0f9dcd01c667bed322df/lib/commons-core/src/main/java/org/apache/olingo/commons/core/edm/EdmTypeInfo.java#L107]:
> {code:java}this.primitiveType =
> EdmPrimitiveTypeKind.valueOf(this.fullQualifiedName.getName());{code}
> When the code generator tries to access the type of the entity it throws a
> NullPointerException.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OLINGO-1167) Pojogen fails when resource has same name as primitive type
Simon Ammer created OLINGO-1167:
---
Summary: Pojogen fails when resource has same name as primitive
type
Key: OLINGO-1167
URL: https://issues.apache.org/jira/browse/OLINGO-1167
Project: Olingo
Issue Type: Bug
Components: odata4-commons, odata4-ext
Affects Versions: (Java) V4 4.3.0, (Java) V4 4.2.0
Environment: EntityType with same name as EdmPrimitiveTypeKind. For
instance: Binary
Reporter: Simon Ammer
Priority: Critical
At some parts Olingo does not use the fully qualified name of a resource to
reference it.Therefore _pojogen_ fails when you have a resource with the same
name as a value defined in
[EdmPrimitiveTypeKind.java|https://github.com/apache/olingo-odata4/blob/6bc17b668c16bbf96458c996bb9d9a768c74dc98/lib/commons-api/src/main/java/org/apache/olingo/commons/api/edm/EdmPrimitiveTypeKind.java].
Take the following scenario:
*$metadata*
{code:xml}
...
...
{code}
My {{self.edu.Binary}} resource match with the primitive kind {{Edm.Binary}}
due to the check in
[EdmTypeInfo.java|https://github.com/apache/olingo-odata4/blob/4a51d16425144a7de0be0f9dcd01c667bed322df/lib/commons-core/src/main/java/org/apache/olingo/commons/core/edm/EdmTypeInfo.java#L107]:
{code:java}this.primitiveType =
EdmPrimitiveTypeKind.valueOf(this.fullQualifiedName.getName());{code}
When the code generator tries to access the type of the entity which would not
been done for primitives it throws a NullPointerException.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (OLINGO-1166) Annotations for members of Enum types in the CSDL appear as siblings instead of as children
Tom van Wietmarschen created OLINGO-1166:
Summary: 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
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] [Commented] (OLINGO-1156) ODataJPAServiceFactory - Cannot create or update entry with ManyToOne association
[ https://issues.apache.org/jira/browse/OLINGO-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16130187#comment-16130187 ] Tilo Eilebrecht commented on OLINGO-1156: - Increasing Priority to Blocker as this stops our development. In my eyes this is a major point - it makes it impossible to work with objects that have navigation properties (at least when theys need to be updated). > ODataJPAServiceFactory - Cannot create or update entry with ManyToOne > association > - > > Key: OLINGO-1156 > URL: https://issues.apache.org/jira/browse/OLINGO-1156 > Project: Olingo > Issue Type: Bug > Components: odata2-jpa >Affects Versions: V2 2.0.9 > Environment: EclipseLink 2.5.2 >Reporter: Tilo Eilebrecht >Priority: Blocker > Attachments: Alternative.java, Scope.java > > > My project uses ODataJPAServiceFactory as described in the tutorial for JPA. > I have an entity which references another entity with a ManyToOne > relationship. If I submit a create or change request, the reference > (idAlternative) is not created or updated. As the field is not nullable, > object creation fails altogether. > See my Entities in the attachment. The JoinColumn is idAlternative. > I have investigated into possible causes and I stumbled on > org.apache.olingo.odata2.jpa.processor.core.access.dataJPAEntity, method > write. This method identifies idAlternative as an embeddable key and removes > it from the propertyNames set. Therefore it does not get written into the > object. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (OLINGO-1156) ODataJPAServiceFactory - Cannot create or update entry with ManyToOne association
[ https://issues.apache.org/jira/browse/OLINGO-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilo Eilebrecht updated OLINGO-1156: Priority: Blocker (was: Major) > ODataJPAServiceFactory - Cannot create or update entry with ManyToOne > association > - > > Key: OLINGO-1156 > URL: https://issues.apache.org/jira/browse/OLINGO-1156 > Project: Olingo > Issue Type: Bug > Components: odata2-jpa >Affects Versions: V2 2.0.9 > Environment: EclipseLink 2.5.2 >Reporter: Tilo Eilebrecht >Priority: Blocker > Attachments: Alternative.java, Scope.java > > > My project uses ODataJPAServiceFactory as described in the tutorial for JPA. > I have an entity which references another entity with a ManyToOne > relationship. If I submit a create or change request, the reference > (idAlternative) is not created or updated. As the field is not nullable, > object creation fails altogether. > See my Entities in the attachment. The JoinColumn is idAlternative. > I have investigated into possible causes and I stumbled on > org.apache.olingo.odata2.jpa.processor.core.access.dataJPAEntity, method > write. This method identifies idAlternative as an embeddable key and removes > it from the propertyNames set. Therefore it does not get written into the > object. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
