We now don't import XML configuration located in classpath*:META-INF/spring-data-rest/**/*.xml anymore. This is primarily to not trigger the XML subsystem in Spring Framework which we don't need at all actually. Users still relying on that import can just declare the import themselves.
Improving the configuration situation for RRCD, whose bean declaration required access to all RepositoryRestConfigurer instances while implementing the interface itself, too. We now rather hide the creation of that instance in a Lazy as it doesn't need any kind of lifecycle management.
We're now registering an HttpMessageConverter to render requests for HAL FORMS using the HalFormsConfiguration present in the application.
We're currently not adding any affordances yet. The change solely enables user code to add affordances explicitly, e.g. via RepresentationModelProcessor implementations.
Fixes: #1991.
RepositoryRestConfigurerAdapter was superceded by RepositoryRestConfigurer and its default methods a long time ago. Update the ref docs to properly use the new interface.
Fixes#1983.
We now properly handle jMolecules Identifier instances by integration with the corresponding Converter implementations provided by the jmolecules-spring integrations library.
Fixes GH-1982.
RepositoryRestConfiguration now defaults the LinkRelationProvider instance to a delegating one considering both AnnotationLinkRelationProvider and EvoLinkRelationProvider so that @Relation annotations on entity types.
Instead of registering the PathPatternParser on DelegatingHandlerMapping via WebMvcConfigurer.configurePathMatch(…) we now consume the bean exposed in context of the fix for spring-projects/spring-framework#26427.
We also use the newly introduced RequestMappingInfo.mutate() to add our customizations of the produces clause for Spring Data REST's mappings.
Fixes GH-1965.
NestedEntitySerializer now skips the wrapping into an EntityModel if the target serializer is a JsonValueSerializer as EntityModel requires the value to ultimately resolve into key value pairs as it's only enriching something that's rendered as JSON document with hypermedia elements.
We actually do not want to inherit all the functionality implemented in AbstractHandlerMapping. The sole reason we did so before was to override the method to propagate the PathPatternResolver to the downstream HandlerMappings. We now just declare the method on DHM directly.
Fixes GH-1955.
