The standard Spring MVC observability integration registers the plain request pattern for observations. For our repository controllers that would result in one pattern registered for all individual repository resources (e.g. /{repository}/{id} etc.). However, the insights users would like to gain rather follows the individual repositories exposed. That's why we have so far exposed repository specific path pattern (/myrepo/{id}) via a custom request attribute. To adhere to the new observability integration of Spring Framework 6, we need to expose that particular pattern on the ServerRequestObservationContext, too.
Fixes#2212.
We now register @BasePathAwareController instances for class proxy generation. Also, we scan the packages of repository definitions for projection interfaces to register reflective access for them.
Fixes#2183.
RepositoryRestMvcConfiguration now implements EmbeddedValueResolver to forward the StringValueResolver given to both BasePathAwareHandlerMapping and RepositoryRestHandlerMapping.
Related ticket: #2157.
Introduce bytebuddy exclusions to avoid clashes with Mockito-provided byte buddy versions. Extend version range in Jackson Hibernate module registrar.
Closes#2158
Added test case and re-enabled the base URI to be prepended even in case a controller path prefix is configured. That functionality had been lost with the originally submitted changes.
Related ticket: #2157
Original pull request: #2088.
This commit introduces support for a common base path shared amongst all handler methods of a controller annotated with @BasePathAwareController / @RepositoryRestController.
Related ticket: #2157
Original pull request: #2088.
The test started to fail when Spring Framework 6 disabled trailing slash path matching (see spring-projects/spring-framework#28552 for details). If adapted to the non-trailing version, it basically duplicates another test already present in the test class.
We now replace the original value of polymorphic properties with the newly deserialized one if the type of the new one is different from the old one. We still copy all JSON ignored properties to the new instance to make sure that non-exposed, server-side state is retained. We apply the same handling for explicitly immutable source and/or target types.
Fixes#2130.
Remove temporary version placeholders and obsolete version declarations for modules we do not test against anymore.
Tweaked the JPA integration and the Jackson Hibernate 5 one in particular to work with the new Jakarta variants. Re-enabled JPA tests. Removed support for Jackson Hibernate 4 integration and JodaTime.
RepositoryRestHandlerMapping's RepositoryCorsConfigurationAccessor now also evaluates @CrossOrigin's originPatterns into the CorsConfiguration.
Fixes#2077.
We now verify that the serializer registered for the type that's supposed to be handled by the NestedEntitySerializer actually supports unwrapping as the serialization in EntityModel (MapSuppressingUnwrappingSerializer) requires that to work properly.
Fixes#2056.
When we detected @BasePathAwareController and @RepositoryRestController instances, we now reject types that use @RequestMapping on the class level as doing so causes an inevitable registration of the controller with Spring MVC.
Fixes#1342, #1628, #1686, #1946.
Whenever HAL FORMS is supposed to be rendered, we now adapt the `Content-Type` header depending on whether affordances (and thus `_templates`) are present. If none can be found, we either adapt the header to either `application/hal+json` or even `application/json` depending on the `Accept` header arrangement given. If none match, we reject the request with `406 Not Acceptable`.
Had to reintroduce a dependency on Lombok to use @SneakyThrows as otherwise we cannot throw HttpMediaTypeNotAcceptableException from a ResponseBodyAdvice. A manual implementation of the pattern does not compile on Java 8 (at least on MacOS).
Fixes#2060.
We now completely avoid reflection in RepositoryRestMvcConfiguration by delaying all bean lookups that were previously declared through autowired fields.
Fixes#2057.
LinkCollector is now an interface. The actual implementation has been moved to DefaultLinkCollector. RepositoryRestConfigurer now has a customizeLinkCollector(…) callback method to tweak or even completely replace the LinkCollector instance.
Fixes#2042.
Introduced RepositoryRestConfigurer.customizeAuditableBeanWrapperFactory(…) so that implementations can customize the default instance provided by RepositoryRestMvcConfiguration.
Fixes#2040.
In AggregateReferenceDeserializerModifier we now look up the original property name on the Jackson metadata before trying to resolve the property target type. We also explicitly guard against null values returned from that lookup and opt out of the customization in those cases.
We now also implement MatchableHandlerMapping.getPatternParser() to expose the PathPatternParser we use. This is needed to detect that DelegatingHandlerMapping uses a PathPatternParser from the outside as the Spring MVC request processing pipeline treats those HandlerMappings in a special way. This is especially important in the context of spring-projects/spring-framework#26814 as that makes the HM implementations work properly in CORS preflight requests.
When used with Spring Security in place, CORS preflight requests are inspected through the HandlerMappingIntrospector, that looks up the CORS configuration for the handler to serve the actual request. That lookup previously failed as Spring MVC was unable to detect that Spring Data REST's DelegatingHandlerMapping works with a PathPatternParser and didn't properly set up the processing pipeline to eventually end up in an invalid state, produce an exception that caused the handler method lookup to fail and cause Spring Security to fail with a 403, claiming the request was invalid.
Fixes#2007.
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.
