Generics bounds too strict in RepresentationModelAssemblerSupport #1126
Assignees
Milestone
Comments
odrotbohm
added a commit
that referenced
this issue
Nov 22, 2019
…port. We constrained the RepresentationModel type parameter in a way that non of the RepresentationModel subclasses we provide aren't usable with it. That's now fixed by loosing that restriction to an arbitrary type.
odrotbohm
changed the title
Bert-R
added a commit
to yonadev/yona-server
that referenced
this issue
Dec 18, 2019
This release includes spring-projects/spring-hateoas#1126 and spring-projects/spring-hateoas#1130, so no need to wait for 1.1.0.
Bert-R
added a commit
to yonadev/yona-server
that referenced
this issue
Feb 10, 2020
* YD-659 Ran Spring Hateoas migration script And made some manual changes. Many other changes are needed to get to Spring Hateaos 1.0.1 * YD-659 Use SimpleRepresentationModelAssembler ControllerBase now requires the interface RepresentationModelAssembler rather than the implementation class RepresentationModelAssemblerSupport. * YD-659 Everything compiles again Using a snapshot build of Spring Hateoas 1.1.0.M1 * YD-659 Fixed the unit tests We now use the Mockito version that comes with the Spring Boot version. Upgraded the equalsverifier to see whether it fixed our issue (it didn't). Then fixed the GoalDtoTest and removed a deprecation warning from DeviceServiceTest.java * YD-659 Made the integration tests work again Along with this standardized naming and type for link relations. They are all defined as LinkRelation XXX_REL. The message handlers need the name as well (for a switch statement). In that case, the string is defined as XXX_REL_NAME. * YD-659 Removed workaround for Spring Hateoas issue Issue spring-projects/spring-hateoas#703 is resolved in 1.1.0.M1, so removed the workaround. To verify this, the test password now includes a character that needs to be encoded, and the integration test verifies that this encoding is done properly. It is not strictly necessary to do this, as we nowadays only generate temp passwords that do not need encoding. However, the test was extended as the web service layer should not depend on the password strategy. * YD-659 Switched to Spring Hateoas 1.0.2 This release includes spring-projects/spring-hateoas#1126 and spring-projects/spring-hateoas#1130, so no need to wait for 1.1.0. * YD-659 Upgrade to Spring Boot 2.2.2 This includes Spring Hateoas 1.0.2 * YD-659 Removed direct spring-hateoas dependency It comes along with the starter already and the version number was wrong. * YD-659 Addressed SonarQube feedback * Used a method reference instead of a call * Removed unused import * YD-659 Upgraded to Spring Boot 2.2.3 This caused an issue that is resolved in Gradle 6.1, so upgraded to that. That however requires a newer version of the Gradle Docker plugin, so upgraded that to the latest version (6.1.2) * YD-659 Addressed review comments * Corrected comment in SecurityProperties (was accidentally updated by Spring HATEOAS upgrade script) * Corrected comment in CreateUserOnBuddyRequestTest.Hacking attempt: Try to get a user created on buddy request with normal Yona password header() * Replaced ActivityControllerBase.PREV_REL and ActivityControllerBase.NEXT_REL with IanaLinkRelations.PREV and IanaLinkRelations.NEXT respectively. * Replaced JsonRootLinkRelationProvider.EDIT_REL with IanaLinkRelations.EDIT * YD-659 Upgraded to Spring Boot 2.2.4 The issue that triggered the upgrade to Gradle 6.1 (spring-projects/spring-boot#19783) is resolved in this version, so strictly speaking, we can stick with the previous version of Gradle (and the Docker plug-in), but everything works, so let's move along.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Backport of #1122.
The text was updated successfully, but these errors were encountered: