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.
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, #2054.
Removed the language of oppression and violence and replaced it with more neutral language.
Note that problematic words in the code have to remain in the docs until the code changes.
Fixes#379.
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 consider all registered PersistentEntity instances and try to detect repository metadata for them. A case we didn't cover before was that a repository was declared for an aggregate super type but the actual child aggregate class didn't have a dedicated repository declared. While this is a perfectly valid scenario, the mapping information was broken as it fell back on the plain domain type information and produced paths and relation names derived from that, even if there's a super type repository available.
Thus, solely traversing the aggregate types we have repositories registered for is not enough. We now traverse all known PersistentEntity types and also register repository metadata for all types that are assignable to a known domain type. The latter is actually implemented in Spring Data Commons' Repositories via spring-projects/spring-data-commons#2406.
