For entity types that use transient fields, the validation integration needs to treat those as normal bean types an must not reject the values right away.
Fixes GH-2252.
We now support using AggregateReference as type to bind request parameters taking URIs pointing to related aggregates. The default resolution will try to resolve the entire URI via UriToEntityConverter but one can also provide a function that can extract any part of the URI to be then resolved into either an identifier, aggregate instance or jMolecules Association against the ConversionService.
Fixes#2239.
RepositoryRestConfiguration now allows to configure to return a response body for the deletion of item resources. The controller implementation follows the same patter we have already established for creation and updates: unless explicitly enabled or disabled we now consider the presence of an accept header as indicator of whether a response body should be rendered.
This could be a "breaking" change for clients having explicitly expected 204 until now even for requests with an Accept header. If that's an issue, those should either explicitly disable the setting, do not submit an Accept header or loosen their expectations to expect either 200 or 2xx as indicator of success in general.
Fixes#2225.
We now consider all registered PersistentEntity instances and try to detect repository metadata for them. A case we didn't cover before was that a repository was declared for an aggregate super type but the actual child aggregate class didn't have a dedicated repository declared. While this is a perfectly valid scenario, the mapping information was broken as it fell back on the plain domain type information and produced paths and relation names derived from that, even if there's a super type repository available.
Thus, solely traversing the aggregate types we have repositories registered for is not enough. We now traverse all known PersistentEntity types and also register repository metadata for all types that are assignable to a known domain type. The latter is actually implemented in Spring Data Commons' Repositories via spring-projects/spring-data-commons#2406.
Nested entities that contain a reference to an aggregate root get a link to that attached to their representation. Previously, the creation of those links assumed that the reference is a materialized instance of the remote aggregate. That's now altered to be able to deal with associations, use identifiers directly or materialize to an intermediate aggregate instance to potentially use a custom lookup.
RepositoryRestConfiguration now defaults the LinkRelationProvider instance to a delegating one considering both AnnotationLinkRelationProvider and EvoLinkRelationProvider so that @Relation annotations on entity types.
Finally remove the dependency to Spring WebMVC from Spring Data REST's core module. Removed previously deprecated methods and update test configuration applying customizations.
Related tickets: DATAREST-1543.
Removed Java8PluginRegistry not in use anymore anyway. Same for RepositoryRestConfigurerAdapter. Deprecated legacy ResourceMappingUtils and its client code exposed in RepositoryRestConfiguration as it's also not considered anymore.
Slightly tweaked the configuration model to rather handle the CorsRegistry via RepositoryRestConfigurer.configureRepositoryRestConfiguration(…) rather than RepositoryRestConfiguration itself. That allows moving of Spring WebMVC as a dependency in the core module.
The original methods exposing access to the CorsRegistry are now still available in deprecated form to not break existing clients.
Follow-up ticket: DATAREST-1542.
We now use Spring's path prefix capabilities to apply Spring Data REST's base path to its mappings. This was previously implemented by tweaking the matching conditions.
We now also pick up Spring 5.3's PathPatternParser and apply that to the custom HandlerMapping implementations we register.
Moved DelegatingHandlerMapping into the configuration package to be able to keep it around in package scope.
Deprecated RepositoryRestConfiguration.getBaseUri() as we have only supported paths for quite a while now. Moved all client code to ….getBasePath() instead.
We use now consistently ConcurrentHashMap instead of ConcurrentReferenceHashMap to avoid object eviction by GC runs as some caches are accessed in a way that does not allow for lazy recomputation of values.
Moved off Spring Framework deprecations for HttpMessageNotReadableException. This required some rearrangements of method signatures for types (hopefully) exclusively used by internal abstractions (some public, but not very friendly for user extension in the first place).
Switched to consistent use of Pageable.unpaged() instead of null. Switched to the use of new factory methods in Spring HATEOAS. Some Java 8 based improvements in request handling to simplify the implementation code. Deprecation of code that got obsolete due to the use of the factory methods.
Moved off some deprecations in Jackson APIs.
Removed a couple of unused imports. General avoidance of common warnings. Suppression where needed. Removed dead code in configuration.
