August 2013 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-1084) REST resources generated by the REST plugin contains duplicate values in resource representations

by Vineet Reynolds (JIRA)

[ https://issues.jboss.org/browse/FORGE-1084?page=com.atlassian.jira.plugin... ] Vineet Reynolds closed FORGE-1084. ---------------------------------- Fix Version/s: 1.3.4.Final Resolution: Done > REST resources generated by the REST plugin contains duplicate values in resource representations > ------------------------------------------------------------------------------------------------- > > Key: FORGE-1084 > URL: https://issues.jboss.org/browse/FORGE-1084 > Project: Forge > Issue Type: Bug > Components: Builtin Plugins > Affects Versions: 1.3.3.Final > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: 1.3.4.Final > > > The JPQL queries generated by the REST plugin should use the DISTINCT keyword to ensure that duplicate values are eliminated from the query result. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1084) REST resources generated by the REST plugin contains duplicate values in resource representations

by Vineet Reynolds (JIRA)

[ https://issues.jboss.org/browse/FORGE-1084?page=com.atlassian.jira.plugin... ] Vineet Reynolds edited comment on FORGE-1084 at 8/3/13 7:39 AM: ---------------------------------------------------------------- Pushed upstream: https://github.com/forge/core/commit/de7faa6b11298d2ba3fa25203e283e83d7d1... was (Author: vineet.reynolds): Pushed upstream: https://github.com/forge/core/commit/fedb1ca42533cba275271c416f1a8728777c... > REST resources generated by the REST plugin contains duplicate values in resource representations > ------------------------------------------------------------------------------------------------- > > Key: FORGE-1084 > URL: https://issues.jboss.org/browse/FORGE-1084 > Project: Forge > Issue Type: Bug > Components: Builtin Plugins > Affects Versions: 1.3.3.Final > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > > The JPQL queries generated by the REST plugin should use the DISTINCT keyword to ensure that duplicate values are eliminated from the query result. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1084) REST resources generated by the REST plugin contains duplicate values in resource representations

by Vineet Reynolds (JIRA)

[ https://issues.jboss.org/browse/FORGE-1084?page=com.atlassian.jira.plugin... ] Vineet Reynolds closed FORGE-1084. ---------------------------------- Assignee: Vineet Reynolds Resolution: Done Pushed upstream: https://github.com/forge/core/commit/fedb1ca42533cba275271c416f1a8728777c... > REST resources generated by the REST plugin contains duplicate values in resource representations > ------------------------------------------------------------------------------------------------- > > Key: FORGE-1084 > URL: https://issues.jboss.org/browse/FORGE-1084 > Project: Forge > Issue Type: Bug > Components: Builtin Plugins > Affects Versions: 1.3.3.Final > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > > The JPQL queries generated by the REST plugin should use the DISTINCT keyword to ensure that duplicate values are eliminated from the query result. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1084) REST resources generated by the REST plugin contains duplicate values in resource representations

by Vineet Reynolds (JIRA)

Vineet Reynolds created FORGE-1084: -------------------------------------- Summary: REST resources generated by the REST plugin contains duplicate values in resource representations Key: FORGE-1084 URL: https://issues.jboss.org/browse/FORGE-1084 Project: Forge Issue Type: Bug Components: Builtin Plugins Affects Versions: 1.3.3.Final Reporter: Vineet Reynolds The JPQL queries generated by the REST plugin should use the DISTINCT keyword to ensure that duplicate values are eliminated from the query result. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1076) REST plugin should detect conflicting top-level paths

by Vineet Reynolds (JIRA)

[ https://issues.jboss.org/browse/FORGE-1076?page=com.atlassian.jira.plugin... ] Vineet Reynolds closed FORGE-1076. ---------------------------------- Assignee: Vineet Reynolds Fix Version/s: 1.3.4.Final Resolution: Done Pushed upstream: https://github.com/forge/core/commit/ced1c2cd63f17f3bcb93ed61f7bc482af421... > REST plugin should detect conflicting top-level paths > ----------------------------------------------------- > > Key: FORGE-1076 > URL: https://issues.jboss.org/browse/FORGE-1076 > Project: Forge > Issue Type: Sub-task > Components: Builtin Plugins > Affects Versions: 1.3.3.Final > Reporter: Vineet Reynolds > Assignee: Vineet Reynolds > Fix For: 1.3.4.Final > > > The REST plugin should detect conflicts for {{@Path}} s defined at the level of a class. A visitor of {{JavaSource}} instances can be used to implement this. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1045) Unit tests should not have a fixed version

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1045?page=com.atlassian.jira.plugin... ] Lincoln Baxter III reassigned FORGE-1045: ----------------------------------------- Assignee: George Gastaldi Failure reproducible by removing ~/.m2/repository/org/jboss/forge/addon, and simulating what the release plugin does: {code}mvn clean verify{code} These are the steps that the release:prepare is failing on. I think it's a problem where the sub-build is not aware of the reactor state. The following workaround would probably succeed, but I'm interested to know if this can be fixed another way: http://stackoverflow.com/questions/4991640/maven-releaseprepare-not-deplo... > Unit tests should not have a fixed version > ------------------------------------------ > > Key: FORGE-1045 > URL: https://issues.jboss.org/browse/FORGE-1045 > Project: Forge > Issue Type: Enhancement > Components: Test Harness > Affects Versions: 2.0.0.Alpha7 > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 2.0.0.Alpha10 > > > Tests now depend on 2.0.0-SNAPSHOT, which may fail when a new version of the addon dependency is released. > We should find some way to avoid declaring the addon dependencies version directly in the Java class. > Excerpt from IRC: > {quote} > <gastaldi> lincolnthree, about the version in the dependencies > <gastaldi> in the tests > <lincolnthree> yes > <gastaldi> What if we consider that if no @Dependencies annotation were provided it should use the pom's dependencies ? > <lincolnthree> can't do that > <gastaldi> why ? > <lincolnthree> because you should be able to depend on dependencies that don't exist > <lincolnthree> without having to remove them from the pom > <lincolnthree> it's a valid failure scenario (laughs at that wording) > <lincolnthree> so we need to be able to test it > <lincolnthree> gastaldi: i would much prefer setting the version to "POM" > <lincolnthree> or omitting the version entirely > <lincolnthree> from the @AddonDependency annotation > <gastaldi> I think it's already optional, no ? > <lincolnthree> it is > <lincolnthree> and the default is LATEST > <lincolnthree> default should probably be POM, which we should intercept and replace with the pom version > <lincolnthree> or throw a deployment exception if it could not be resolved > <gastaldi> I see > <lincolnthree> thoughts? > <gastaldi> What about the AddonDependencyEntry.create statements ? > <gastaldi> sounds fair so far > <gastaldi> we could introduce a new method in ForgeArchive > <gastaldi> addAddonDependenciesAsDeclaredInPOMForGodsSake() > <lincolnthree> ah… right > <lincolnthree> well > <lincolnthree> the version there doesn't matter, remember? > <lincolnthree> so we could actually make the version optional > <lincolnthree> it could default to "anything" > <gastaldi> so so we need a AnythingGoesVersion implements Version subclass > <gastaldi> an enum > <gastaldi> public enum Anything implements Version { INSTANCE;} > <gastaldi> hum, or the version could be empty, right > <gastaldi> in that case there is already the EmptyVersion class > <lincolnthree> right > {quote} -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1045) Unit tests should not have a fixed version

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1045?page=com.atlassian.jira.plugin... ] Lincoln Baxter III reopened FORGE-1045: --------------------------------------- Assignee: Lincoln Baxter III (was: George Gastaldi) > Unit tests should not have a fixed version > ------------------------------------------ > > Key: FORGE-1045 > URL: https://issues.jboss.org/browse/FORGE-1045 > Project: Forge > Issue Type: Enhancement > Components: Test Harness > Affects Versions: 2.0.0.Alpha7 > Reporter: George Gastaldi > Assignee: Lincoln Baxter III > Fix For: 2.0.0.Alpha10 > > > Tests now depend on 2.0.0-SNAPSHOT, which may fail when a new version of the addon dependency is released. > We should find some way to avoid declaring the addon dependencies version directly in the Java class. > Excerpt from IRC: > {quote} > <gastaldi> lincolnthree, about the version in the dependencies > <gastaldi> in the tests > <lincolnthree> yes > <gastaldi> What if we consider that if no @Dependencies annotation were provided it should use the pom's dependencies ? > <lincolnthree> can't do that > <gastaldi> why ? > <lincolnthree> because you should be able to depend on dependencies that don't exist > <lincolnthree> without having to remove them from the pom > <lincolnthree> it's a valid failure scenario (laughs at that wording) > <lincolnthree> so we need to be able to test it > <lincolnthree> gastaldi: i would much prefer setting the version to "POM" > <lincolnthree> or omitting the version entirely > <lincolnthree> from the @AddonDependency annotation > <gastaldi> I think it's already optional, no ? > <lincolnthree> it is > <lincolnthree> and the default is LATEST > <lincolnthree> default should probably be POM, which we should intercept and replace with the pom version > <lincolnthree> or throw a deployment exception if it could not be resolved > <gastaldi> I see > <lincolnthree> thoughts? > <gastaldi> What about the AddonDependencyEntry.create statements ? > <gastaldi> sounds fair so far > <gastaldi> we could introduce a new method in ForgeArchive > <gastaldi> addAddonDependenciesAsDeclaredInPOMForGodsSake() > <lincolnthree> ah… right > <lincolnthree> well > <lincolnthree> the version there doesn't matter, remember? > <lincolnthree> so we could actually make the version optional > <lincolnthree> it could default to "anything" > <gastaldi> so so we need a AnythingGoesVersion implements Version subclass > <gastaldi> an enum > <gastaldi> public enum Anything implements Version { INSTANCE;} > <gastaldi> hum, or the version could be empty, right > <gastaldi> in that case there is already the EmptyVersion class > <lincolnthree> right > {quote} -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1045) Unit tests should not have a fixed version

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1045?page=com.atlassian.jira.plugin... ] Lincoln Baxter III reassigned FORGE-1045: ----------------------------------------- Assignee: (was: Lincoln Baxter III) > Unit tests should not have a fixed version > ------------------------------------------ > > Key: FORGE-1045 > URL: https://issues.jboss.org/browse/FORGE-1045 > Project: Forge > Issue Type: Enhancement > Components: Test Harness > Affects Versions: 2.0.0.Alpha7 > Reporter: George Gastaldi > Fix For: 2.0.0.Alpha10 > > > Tests now depend on 2.0.0-SNAPSHOT, which may fail when a new version of the addon dependency is released. > We should find some way to avoid declaring the addon dependencies version directly in the Java class. > Excerpt from IRC: > {quote} > <gastaldi> lincolnthree, about the version in the dependencies > <gastaldi> in the tests > <lincolnthree> yes > <gastaldi> What if we consider that if no @Dependencies annotation were provided it should use the pom's dependencies ? > <lincolnthree> can't do that > <gastaldi> why ? > <lincolnthree> because you should be able to depend on dependencies that don't exist > <lincolnthree> without having to remove them from the pom > <lincolnthree> it's a valid failure scenario (laughs at that wording) > <lincolnthree> so we need to be able to test it > <lincolnthree> gastaldi: i would much prefer setting the version to "POM" > <lincolnthree> or omitting the version entirely > <lincolnthree> from the @AddonDependency annotation > <gastaldi> I think it's already optional, no ? > <lincolnthree> it is > <lincolnthree> and the default is LATEST > <lincolnthree> default should probably be POM, which we should intercept and replace with the pom version > <lincolnthree> or throw a deployment exception if it could not be resolved > <gastaldi> I see > <lincolnthree> thoughts? > <gastaldi> What about the AddonDependencyEntry.create statements ? > <gastaldi> sounds fair so far > <gastaldi> we could introduce a new method in ForgeArchive > <gastaldi> addAddonDependenciesAsDeclaredInPOMForGodsSake() > <lincolnthree> ah… right > <lincolnthree> well > <lincolnthree> the version there doesn't matter, remember? > <lincolnthree> so we could actually make the version optional > <lincolnthree> it could default to "anything" > <gastaldi> so so we need a AnythingGoesVersion implements Version subclass > <gastaldi> an enum > <gastaldi> public enum Anything implements Version { INSTANCE;} > <gastaldi> hum, or the version could be empty, right > <gastaldi> in that case there is already the EmptyVersion class > <lincolnthree> right > {quote} -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1045) Unit tests should not have a fixed version

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-1045?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-1045. ---------------------------------- Resolution: Done Fixed in https://github.com/forge/furnace/commit/01f1c3b1e3174bb848332d09ba601238a... > Unit tests should not have a fixed version > ------------------------------------------ > > Key: FORGE-1045 > URL: https://issues.jboss.org/browse/FORGE-1045 > Project: Forge > Issue Type: Enhancement > Components: Test Harness > Affects Versions: 2.0.0.Alpha7 > Reporter: George Gastaldi > Assignee: George Gastaldi > Fix For: 2.0.0.Alpha10 > > > Tests now depend on 2.0.0-SNAPSHOT, which may fail when a new version of the addon dependency is released. > We should find some way to avoid declaring the addon dependencies version directly in the Java class. > Excerpt from IRC: > {quote} > <gastaldi> lincolnthree, about the version in the dependencies > <gastaldi> in the tests > <lincolnthree> yes > <gastaldi> What if we consider that if no @Dependencies annotation were provided it should use the pom's dependencies ? > <lincolnthree> can't do that > <gastaldi> why ? > <lincolnthree> because you should be able to depend on dependencies that don't exist > <lincolnthree> without having to remove them from the pom > <lincolnthree> it's a valid failure scenario (laughs at that wording) > <lincolnthree> so we need to be able to test it > <lincolnthree> gastaldi: i would much prefer setting the version to "POM" > <lincolnthree> or omitting the version entirely > <lincolnthree> from the @AddonDependency annotation > <gastaldi> I think it's already optional, no ? > <lincolnthree> it is > <lincolnthree> and the default is LATEST > <lincolnthree> default should probably be POM, which we should intercept and replace with the pom version > <lincolnthree> or throw a deployment exception if it could not be resolved > <gastaldi> I see > <lincolnthree> thoughts? > <gastaldi> What about the AddonDependencyEntry.create statements ? > <gastaldi> sounds fair so far > <gastaldi> we could introduce a new method in ForgeArchive > <gastaldi> addAddonDependenciesAsDeclaredInPOMForGodsSake() > <lincolnthree> ah… right > <lincolnthree> well > <lincolnthree> the version there doesn't matter, remember? > <lincolnthree> so we could actually make the version optional > <lincolnthree> it could default to "anything" > <gastaldi> so so we need a AnythingGoesVersion implements Version subclass > <gastaldi> an enum > <gastaldi> public enum Anything implements Version { INSTANCE;} > <gastaldi> hum, or the version could be empty, right > <gastaldi> in that case there is already the EmptyVersion class > <lincolnthree> right > {quote} -- 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

10 years, 11 months

1
0
0 / 0

[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: ---------------------------------------- The current REST plugin enhances the base JPA entities for the REST resources with {{@XmlRootElement}} annotations. This would need to be done away with, but introduced in the DTOs. > 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

10 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues August 2013