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.
