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.
Previously the backend identifier derived from the URI was set as identifier on the object to be created in a PUT request. However, in case a custom entity lookup is used, this is not the identifier but an arbitrary property pointed to through user defined code, mostly a method reference.
We now use the newly introduced MethodInvocationRecorder API in Spring Data Commons to be able to obtain the property that is supposed to be used and set that to the value calculated. This requires the entity type for which the custom lookup is configured to be non-final as the invocation recording is build on top of proxies.
Related tickets: DATACMNS-1449.
We now properly only answer PersistentEntitiesResourceMappings.hasMappingsFor(…) with true if we find a non-null value in the cache. Previously, even a failed attempt to create some ResourceMapping would've caused ….hasMappingsFor(…) to indicate it PersistentEntitiesResourceMappings contains a mapping.
This lead to downstream NullPointerExceptions as ….getMetadataFor(…) was accessed without a null guard after ….hasMappingFor(…) returned true.
DomainObjectReader now aborts the recursive merges in case it encounters an entity that's described as @Immutable (just introduced in Spring Data Commons).
Fixed some generics and removed DomainObjectMerger as it's unused.
Related ticket: DATACMNS-1322.
Fixed @since tag in new converter implementation as we're going to backport the fix to Kay. Simplified converter setup in RepositoryRestMvcConfiguration to expose less API until someone actually requests access.
Original pull request: #290.
We now provide and configure a converter for String to LdapName conversion so Spring Data LDAP can be used with Spring Data REST without further configuration.
Original pull request: #290.
ExposureConfiguration exposes methods to register AggregateResourceHttpMethodsFilter and AssociationResourceHttpMethodsFilter (both applied by type or globally) to customize the supported HTTP methods by collection, item and association resources. It also provides shortcuts for common use cases like disabling PUT for item resources etc.
The default exposure of repository methods is now controlled via RepositoryRestConfiguration.setExposeRepositoryMethodsByDefault(…). That allows us to remove the additional API from RepositoryDetectionStrategy as the mere detection is an orthogonal topic.
Also added RepositoryRestConfiguration.disableDefaultExposure() to set the RepositoryDetectionStategy to ANNOTATED and disables default method exposure in one go. That can be exposed via a Spring Boot configuration property downstream.
Moved the flag to decide whether to expose repository methods by default to the RepositoryDetectionStrategy interface, so that it can be directly accessed and the test on the particular enum value is not needed anymore and thus also not duplicated into different parts of the codebase.
Added more tests to actually verify behavior on CrudMethodsSupportedHttpMethods. DefaultExposureAwareCrudMethods uses @RequiredArgumentConstructor again.
The field value lookup in ValidationErrors previously threw a NotReadablePropertyException in case a property value was null as we incorrectly piped the null value into an Optional in turn. We now eagerly reject the property if we can't find a PersistentProperty in the metamodel to avoid this.
