[JBoss JIRA] (FORGE-1060) REST plugin should support creation of DTOs for the underlying JPA entities of REST resources
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-1060?page=com.atlassian.jira.plugin... ]
Vineet Reynolds updated FORGE-1060:
-----------------------------------
Description:
Using JPA entities directly in the REST resources is obviously not proving to be of much help:
* It leads to problems when working with cyclic dependencies, as seen in FORGE-606. Using {{@JsonIdentityInfo}} to resolve this has lead to further problems on the client side due to the lack of support in JavaScript clients to handle JSON object references out of the box.
* It requires the entire object graph to be eagerly fetched and made available during the serialization process. During deserialization, JPA merges could result in incorrect behavior since merges of object graphs depend on whether the collection was previously fetched or not. Merges are not expected to occur by spec, unless the collection was fetched. See [HHH-4135|https://hibernate.atlassian.net/browse/HHH-4135] and[HHH-5187|https://hibernate.atlassian.net/browse/HHH-5187] for some details on Hibernate, with differing behavior in EclipseLink.
* It requires manipulation of the relational associations across entities to modify the resource representations, thus lacking separation of concerns.
* It provides no control over the depth of the object graph to be serialized. Annotations like {{@JsonIgnore}} are required to be placed on JPA entities which does not aid in separation of concerns. Custom serializers/deserializers offer little benefit concerning standards since they requires compilation against specific versions of the JSON libraries like Jackson for every container that is to be supported.
Therefore it is proposed to have the REST plugin create DTOs for representing the state of the JPA entities in the REST resources.
was:
Using JPA entities directly in the REST resources is obviously not proving to be of much help:
* It leads to problems when working with cyclic dependencies, as seen in FORGE-606. Using {{@JsonIdentityInfo}} to resolve this has lead to further problems on the client side due to the lack of support in JavaScript clients to handle JSON object references out of the box.
* It requires manipulation of the relational associations across entities to modify the resource representations, thus lacking separation of concerns.
* It provides no control over the depth of the object graph to be serialized. Annotations like {{@JsonIgnore}} are required to be placed on JPA entities which does not aid in separation of concerns. Custom serializers/deserializers offer little benefit concerning standards since they requires compilation against specific versions of the JSON libraries like Jackson for every container that is to be supported.
Therefore it is proposed to have the REST plugin create DTOs for representing the state of the JPA entities in the REST resources.
> REST plugin should support creation of DTOs for the underlying JPA entities of REST resources
> ---------------------------------------------------------------------------------------------
>
> Key: FORGE-1060
> URL: https://issues.jboss.org/browse/FORGE-1060
> Project: Forge
> Issue Type: Feature Request
> Components: Builtin Plugins
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
> Priority: Critical
>
> Using JPA entities directly in the REST resources is obviously not proving to be of much help:
> * It leads to problems when working with cyclic dependencies, as seen in FORGE-606. Using {{@JsonIdentityInfo}} to resolve this has lead to further problems on the client side due to the lack of support in JavaScript clients to handle JSON object references out of the box.
> * It requires the entire object graph to be eagerly fetched and made available during the serialization process. During deserialization, JPA merges could result in incorrect behavior since merges of object graphs depend on whether the collection was previously fetched or not. Merges are not expected to occur by spec, unless the collection was fetched. See [HHH-4135|https://hibernate.atlassian.net/browse/HHH-4135] and[HHH-5187|https://hibernate.atlassian.net/browse/HHH-5187] for some details on Hibernate, with differing behavior in EclipseLink.
> * It requires manipulation of the relational associations across entities to modify the resource representations, thus lacking separation of concerns.
> * It provides no control over the depth of the object graph to be serialized. Annotations like {{@JsonIgnore}} are required to be placed on JPA entities which does not aid in separation of concerns. Custom serializers/deserializers offer little benefit concerning standards since they requires compilation against specific versions of the JSON libraries like Jackson for every container that is to be supported.
> Therefore it is proposed to have the REST plugin create DTOs for representing the state of the JPA entities in the REST resources.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (FORGE-1060) REST plugin should support creation of DTOs for the underlying JPA entities of REST resources
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-1060?page=com.atlassian.jira.plugin... ]
Vineet Reynolds commented on FORGE-1060:
----------------------------------------
A discussion on StackOverflow on the same topic: http://stackoverflow.com/questions/17874688/what-is-a-good-strategy-for-c...
> REST plugin should support creation of DTOs for the underlying JPA entities of REST resources
> ---------------------------------------------------------------------------------------------
>
> Key: FORGE-1060
> URL: https://issues.jboss.org/browse/FORGE-1060
> Project: Forge
> Issue Type: Feature Request
> Components: Builtin Plugins
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
> Priority: Critical
>
> Using JPA entities directly in the REST resources is obviously not proving to be of much help:
> * It leads to problems when working with cyclic dependencies, as seen in FORGE-606. Using {{@JsonIdentityInfo}} to resolve this has lead to further problems on the client side due to the lack of support in JavaScript clients to handle JSON object references out of the box.
> * It requires the entire object graph to be eagerly fetched and made available during the serialization process. During deserialization, JPA merges could result in incorrect behavior since merges of object graphs depend on whether the collection was previously fetched or not. Merges are not expected to occur by spec, unless the collection was fetched. See [HHH-4135|https://hibernate.atlassian.net/browse/HHH-4135] and [HHH-5187|https://hibernate.atlassian.net/browse/HHH-5187] for some details on Hibernate, with differing behavior in EclipseLink.
> * It requires manipulation of the relational associations across entities to modify the resource representations, thus lacking separation of concerns.
> * It provides no control over the depth of the object graph to be serialized. Annotations like {{@JsonIgnore}} are required to be placed on JPA entities which does not aid in separation of concerns. Custom serializers/deserializers offer little benefit concerning standards since they requires compilation against specific versions of the JSON libraries like Jackson for every container that is to be supported.
> Therefore it is proposed to have the REST plugin create DTOs for representing the state of the JPA entities in the REST resources.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (FORGE-1060) REST plugin should support creation of DTOs for the underlying JPA entities of REST resources
by Vineet Reynolds (JIRA)
[ https://issues.jboss.org/browse/FORGE-1060?page=com.atlassian.jira.plugin... ]
Vineet Reynolds updated FORGE-1060:
-----------------------------------
Description:
Using JPA entities directly in the REST resources is obviously not proving to be of much help:
* It leads to problems when working with cyclic dependencies, as seen in FORGE-606. Using {{@JsonIdentityInfo}} to resolve this has lead to further problems on the client side due to the lack of support in JavaScript clients to handle JSON object references out of the box.
* It requires the entire object graph to be eagerly fetched and made available during the serialization process. During deserialization, JPA merges could result in incorrect behavior since merges of object graphs depend on whether the collection was previously fetched or not. Merges are not expected to occur by spec, unless the collection was fetched. See [HHH-4135|https://hibernate.atlassian.net/browse/HHH-4135] and [HHH-5187|https://hibernate.atlassian.net/browse/HHH-5187] for some details on Hibernate, with differing behavior in EclipseLink.
* It requires manipulation of the relational associations across entities to modify the resource representations, thus lacking separation of concerns.
* It provides no control over the depth of the object graph to be serialized. Annotations like {{@JsonIgnore}} are required to be placed on JPA entities which does not aid in separation of concerns. Custom serializers/deserializers offer little benefit concerning standards since they requires compilation against specific versions of the JSON libraries like Jackson for every container that is to be supported.
Therefore it is proposed to have the REST plugin create DTOs for representing the state of the JPA entities in the REST resources.
was:
Using JPA entities directly in the REST resources is obviously not proving to be of much help:
* It leads to problems when working with cyclic dependencies, as seen in FORGE-606. Using {{@JsonIdentityInfo}} to resolve this has lead to further problems on the client side due to the lack of support in JavaScript clients to handle JSON object references out of the box.
* It requires the entire object graph to be eagerly fetched and made available during the serialization process. During deserialization, JPA merges could result in incorrect behavior since merges of object graphs depend on whether the collection was previously fetched or not. Merges are not expected to occur by spec, unless the collection was fetched. See [HHH-4135|https://hibernate.atlassian.net/browse/HHH-4135] and[HHH-5187|https://hibernate.atlassian.net/browse/HHH-5187] for some details on Hibernate, with differing behavior in EclipseLink.
* It requires manipulation of the relational associations across entities to modify the resource representations, thus lacking separation of concerns.
* It provides no control over the depth of the object graph to be serialized. Annotations like {{@JsonIgnore}} are required to be placed on JPA entities which does not aid in separation of concerns. Custom serializers/deserializers offer little benefit concerning standards since they requires compilation against specific versions of the JSON libraries like Jackson for every container that is to be supported.
Therefore it is proposed to have the REST plugin create DTOs for representing the state of the JPA entities in the REST resources.
> REST plugin should support creation of DTOs for the underlying JPA entities of REST resources
> ---------------------------------------------------------------------------------------------
>
> Key: FORGE-1060
> URL: https://issues.jboss.org/browse/FORGE-1060
> Project: Forge
> Issue Type: Feature Request
> Components: Builtin Plugins
> Reporter: Vineet Reynolds
> Assignee: Vineet Reynolds
> Priority: Critical
>
> Using JPA entities directly in the REST resources is obviously not proving to be of much help:
> * It leads to problems when working with cyclic dependencies, as seen in FORGE-606. Using {{@JsonIdentityInfo}} to resolve this has lead to further problems on the client side due to the lack of support in JavaScript clients to handle JSON object references out of the box.
> * It requires the entire object graph to be eagerly fetched and made available during the serialization process. During deserialization, JPA merges could result in incorrect behavior since merges of object graphs depend on whether the collection was previously fetched or not. Merges are not expected to occur by spec, unless the collection was fetched. See [HHH-4135|https://hibernate.atlassian.net/browse/HHH-4135] and [HHH-5187|https://hibernate.atlassian.net/browse/HHH-5187] for some details on Hibernate, with differing behavior in EclipseLink.
> * It requires manipulation of the relational associations across entities to modify the resource representations, thus lacking separation of concerns.
> * It provides no control over the depth of the object graph to be serialized. Annotations like {{@JsonIgnore}} are required to be placed on JPA entities which does not aid in separation of concerns. Custom serializers/deserializers offer little benefit concerning standards since they requires compilation against specific versions of the JSON libraries like Jackson for every container that is to be supported.
> Therefore it is proposed to have the REST plugin create DTOs for representing the state of the JPA entities in the REST resources.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (FORGE-1030) Repository.yaml does not use given project in multi-module Forge plugins
by Lennart Jörelid (JIRA)
[ https://issues.jboss.org/browse/FORGE-1030?page=com.atlassian.jira.plugin... ]
Lennart Jörelid commented on FORGE-1030:
----------------------------------------
This problem effectively prohibits Forge to discover plugins in anything but the topmost project.
This, in turn, effectively prohibits anyone from using anything but a single project for defining Forge plugins.
> Repository.yaml does not use given project in multi-module Forge plugins
> ------------------------------------------------------------------------
>
> Key: FORGE-1030
> URL: https://issues.jboss.org/browse/FORGE-1030
> Project: Forge
> Issue Type: Bug
> Components: Documentation, Plugin API, Plugin Repository
> Affects Versions: 1.3.3.Final
> Reporter: Lennart Jörelid
> Priority: Blocker
>
> It seems that Forge really needs better support for the default Maven
> development process. In repository.yaml, Forge plugins are defined by giving
> a Maven project GAV for the project holding the forge plugin definitions, as well as the GitHub repository holding the plugin source.
> Yet, Forge seems to ignore the Maven GAV information given in repository.yaml when checking out and building the plugin locally.
> This is a rather nasty bug, which in its current state effectively prevents anyone from using a multi-module build for their plugins (and it is also undocumented).
> An example is shown below:
> {code}
> [no project] Nazgul $ forge install-plugin nazgul
> ***INFO*** Preparing to install plugin: nazgul
> ***INFO*** Checking out plugin source files to [/var/folders/6g/9n7r543d2bv9n2qjvnvf_hsh0000gn/T/forgetemp6186363544408555570] via 'git'
> ***INFO*** Switching to branch/tag [refs/heads/1.3.3.Final]
> ? The project does not appear to be a Forge Plugin Project, install anyway? [y/N]
> {code}
> While this analysis by Forge is incorrect (the Maven GAV given in the repository.yaml is indeed a project which holds plugins), it gets worse after installation:
> {code}
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] nazgul-forge-parent ............................... SUCCESS [7.921s]
> [INFO] nazgul-forge-api-parent ........................... SUCCESS [4.345s]
> [INFO] nazgul-forge-model-parent ......................... SUCCESS [1.274s]
> [INFO] nazgul-forge-reactor .............................. SUCCESS [0.847s]
> [INFO] nazgul-forge-poms-reactor ......................... SUCCESS [0.058s]
> [INFO] nazgul-forge-analyzer-api ......................... SUCCESS [5.562s]
> [INFO] nazgul-forge-analyzer-impl-nazgul ................. SUCCESS [1.666s]
> [INFO] nazgul-forge-analyzer-reactor ..................... SUCCESS [0.020s]
> [INFO] nazgul-forge-factory-model ........................ SUCCESS [2.434s]
> [INFO] nazgul-forge-factory-api .......................... SUCCESS [7.634s]
> [INFO] nazgul-forge-factory-impl-nazgul .................. SUCCESS [2.724s]
> [INFO] nazgul-forge-factory-reactor ...................... SUCCESS [0.032s]
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 36.580s
> [INFO] Finished at: Mon Jul 22 07:46:48 CEST 2013
> [INFO] Final Memory: 49M/247M
> [INFO] ------------------------------------------------------------------------
> ***INFO*** Cleaning up temp workspace [/var/folders/6g/9n7r543d2bv9n2qjvnvf_hsh0000gn/T/forgetemp6186363544408555570]
> Deleted /var/folders/6g/9n7r543d2bv9n2qjvnvf_hsh0000gn/T/forgetemp6186363544408555570
> ***ERROR*** Exception encountered: Build artifact [nazgul-forge-reactor-1.0.1-SNAPSHOT.pom] is missing and cannot be installed. Please resolve build errors and try again. (type "set VERBOSE true" to enable stack traces)
> {code}
> So ...
> # The repository.yaml includes a full Maven GAV to the project which holds Forge plugins.
> # Forge uses repository.yaml to download the source from GitHub and build it
> # Forge ignores the Maven GAV given in repository.yaml, and simply uses the root reactor project to inspect and attempt to install the plugins.
> To fix this bug, Forge needs to find the project given within the repository.yaml within the downloaded reactor and install the plugins from *that* project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (FORGE-1030) Repository.yaml does not use given project in multi-module Forge plugins
by Lennart Jörelid (JIRA)
[ https://issues.jboss.org/browse/FORGE-1030?page=com.atlassian.jira.plugin... ]
Lennart Jörelid updated FORGE-1030:
-----------------------------------
Priority: Blocker (was: Critical)
> Repository.yaml does not use given project in multi-module Forge plugins
> ------------------------------------------------------------------------
>
> Key: FORGE-1030
> URL: https://issues.jboss.org/browse/FORGE-1030
> Project: Forge
> Issue Type: Bug
> Components: Documentation, Plugin API, Plugin Repository
> Affects Versions: 1.3.3.Final
> Reporter: Lennart Jörelid
> Priority: Blocker
>
> It seems that Forge really needs better support for the default Maven
> development process. In repository.yaml, Forge plugins are defined by giving
> a Maven project GAV for the project holding the forge plugin definitions, as well as the GitHub repository holding the plugin source.
> Yet, Forge seems to ignore the Maven GAV information given in repository.yaml when checking out and building the plugin locally.
> This is a rather nasty bug, which in its current state effectively prevents anyone from using a multi-module build for their plugins (and it is also undocumented).
> An example is shown below:
> {code}
> [no project] Nazgul $ forge install-plugin nazgul
> ***INFO*** Preparing to install plugin: nazgul
> ***INFO*** Checking out plugin source files to [/var/folders/6g/9n7r543d2bv9n2qjvnvf_hsh0000gn/T/forgetemp6186363544408555570] via 'git'
> ***INFO*** Switching to branch/tag [refs/heads/1.3.3.Final]
> ? The project does not appear to be a Forge Plugin Project, install anyway? [y/N]
> {code}
> While this analysis by Forge is incorrect (the Maven GAV given in the repository.yaml is indeed a project which holds plugins), it gets worse after installation:
> {code}
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] nazgul-forge-parent ............................... SUCCESS [7.921s]
> [INFO] nazgul-forge-api-parent ........................... SUCCESS [4.345s]
> [INFO] nazgul-forge-model-parent ......................... SUCCESS [1.274s]
> [INFO] nazgul-forge-reactor .............................. SUCCESS [0.847s]
> [INFO] nazgul-forge-poms-reactor ......................... SUCCESS [0.058s]
> [INFO] nazgul-forge-analyzer-api ......................... SUCCESS [5.562s]
> [INFO] nazgul-forge-analyzer-impl-nazgul ................. SUCCESS [1.666s]
> [INFO] nazgul-forge-analyzer-reactor ..................... SUCCESS [0.020s]
> [INFO] nazgul-forge-factory-model ........................ SUCCESS [2.434s]
> [INFO] nazgul-forge-factory-api .......................... SUCCESS [7.634s]
> [INFO] nazgul-forge-factory-impl-nazgul .................. SUCCESS [2.724s]
> [INFO] nazgul-forge-factory-reactor ...................... SUCCESS [0.032s]
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 36.580s
> [INFO] Finished at: Mon Jul 22 07:46:48 CEST 2013
> [INFO] Final Memory: 49M/247M
> [INFO] ------------------------------------------------------------------------
> ***INFO*** Cleaning up temp workspace [/var/folders/6g/9n7r543d2bv9n2qjvnvf_hsh0000gn/T/forgetemp6186363544408555570]
> Deleted /var/folders/6g/9n7r543d2bv9n2qjvnvf_hsh0000gn/T/forgetemp6186363544408555570
> ***ERROR*** Exception encountered: Build artifact [nazgul-forge-reactor-1.0.1-SNAPSHOT.pom] is missing and cannot be installed. Please resolve build errors and try again. (type "set VERBOSE true" to enable stack traces)
> {code}
> So ...
> # The repository.yaml includes a full Maven GAV to the project which holds Forge plugins.
> # Forge uses repository.yaml to download the source from GitHub and build it
> # Forge ignores the Maven GAV given in repository.yaml, and simply uses the root reactor project to inspect and attempt to install the plugins.
> To fix this bug, Forge needs to find the project given within the repository.yaml within the downloaded reactor and install the plugins from *that* project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (FORGE-1061) REST plugin should support user-driven mapping of DTOs to JPA entities
by Vineet Reynolds (JIRA)
Vineet Reynolds created FORGE-1061:
--------------------------------------
Summary: REST plugin should support user-driven mapping of DTOs to JPA entities
Key: FORGE-1061
URL: https://issues.jboss.org/browse/FORGE-1061
Project: Forge
Issue Type: Feature Request
Components: Builtin Plugins
Affects Versions: 1.3.3.Final
Reporter: Vineet Reynolds
This is to extend the work done in FORGE-1060 which is scoped to generate DTOs in a pre-determined manner for JPA entities. We should be able to support user-driven mapping of the JPA entities to create the DTOs first, and then generate the appropriate business services that would update the underlying entities in the database.
Doing so would allow the REST resources to function in a similar manner to the [REST workflow pattern|http://www.infoq.com/articles/webber-rest-workflow]. This would improve the transactional behavior of the resources, since the constructed DTOs could house all related entities that participate in a business transaction. Since metadata of business transactions is not available in the object model, the mapping process to derive the DTOs will be user-driven.
Not doing so would yield REST resources that are just representations of database tables, thus requiring associations to be established for entities that participate in a business transaction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (FORGE-1060) REST plugin should support creation of DTOs for the underlying JPA entities of REST resources
by Vineet Reynolds (JIRA)
Vineet Reynolds created FORGE-1060:
--------------------------------------
Summary: REST plugin should support creation of DTOs for the underlying JPA entities of REST resources
Key: FORGE-1060
URL: https://issues.jboss.org/browse/FORGE-1060
Project: Forge
Issue Type: Feature Request
Components: Builtin Plugins
Reporter: Vineet Reynolds
Assignee: Vineet Reynolds
Priority: Critical
Using JPA entities directly in the REST resources is obviously not proving to be of much help:
* It leads to problems when working with cyclic dependencies, as seen in FORGE-606. Using {{@JsonIdentityInfo}} to resolve this has lead to further problems on the client side due to the lack of support in JavaScript clients to handle JSON object references out of the box.
* It requires manipulation of the relational associations across entities to modify the resource representations, thus lacking separation of concerns.
* It provides no control over the depth of the object graph to be serialized. Annotations like {{@JsonIgnore}} are required to be placed on JPA entities which does not aid in separation of concerns. Custom serializers/deserializers offer little benefit concerning standards since they requires compilation against specific versions of the JSON libraries like Jackson for every container that is to be supported.
Therefore it is proposed to have the REST plugin create DTOs for representing the state of the JPA entities in the REST resources.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months