4b36f79 introduced a regression by consuming registered RepositoryRestConfigurer instances via ApplicationContext.getBeansOfType(…).values() which, unlike the previous consumption via a List<RRC> in an @Bean method, is losing the declared order of the RRC instances as ….getBeansOfType() is a Map.
We now rather use an ObjectProvider and its ….orderedStream() method to consume the registered instances ordered properly.
Fixes#1995.
Introduce AggregateReferenceResolvingModule to be registered with the default ObjectMapper instance that will allow to materialize aggregate instances from URIs for incoming web requests. We do not apply this for aggregate roots themselves as they're already handled by the AssociationUriResolvingDeserializerModifier.
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.
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.
We now properly handle jMolecules Identifier instances by integration with the corresponding Converter implementations provided by the jmolecules-spring integrations library.
Fixes GH-1982.
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.
We now build against a newer Servlet API version to align with Spring Framework.
Also, introduce a version property servlet.version for centralized version management.
Closes#1951
Switch to ObjectProvider for all component dependencies in the constructor of RepositoryRestMvcConfiguration. Made the bean definition of AnnotatedEventHandlerInvoker a static bean as it's an application listener and it being an instance method causes extend initialization of the configuration class trickling down into unnecessary bean lookups that early in the lifecycle.
The fix for DATAREST-1535 has changed the default allowed methods for CORS requests to a smaller set than we originally returned. This commit reinstantiates the default to be set to all HTTP methods, Spring Data repositories support by default.
Related tickets: DATAREST-1535.
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.
We replaced the component scan in RespositoryRestMvcConfiguration with dedicated bean methods. This allows us to be more explicit in resolving required components, which is required for better support of GraalVM native image.
Original pull request: #382.
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.
Turns out that Spring Boot references DelegatingHandlerMapping from its metrics integration to pick up the HandlerMappings delegated to. Reintroduced the relevant type in deprecated form and also let it implement Iterable<HandlerMapping> so that client code can be moved to generally check for HandlerMappings implementing that and pick up the delegates that way.
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.
