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.
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.
Verify that Jackson properly serializes to ISO-8601 format, which includes three potential timezone endings. Expand CI testing against both Jackson 2.10 and 2.11. Also test these profiles against JDK 8, 11, and 14.
Related: spring-projects/spring-data-build#1075
Original pull request: #374.
We now use the current request's URI as base link for all links created for a collection resource. This especially has effect in the creation of pagination links as we now carry potentially applied critierias (induced by our Querydsl based filtering support) forward to the navigation links generated.
Moved off Spring Framework deprecations for HttpMessageNotReadableException. This required some rearrangements of method signatures for types (hopefully) exclusively used by internal abstractions (some public, but not very friendly for user extension in the first place).
Switched to consistent use of Pageable.unpaged() instead of null. Switched to the use of new factory methods in Spring HATEOAS. Some Java 8 based improvements in request handling to simplify the implementation code. Deprecation of code that got obsolete due to the use of the factory methods.
Moved off some deprecations in Jackson APIs.
Removed a couple of unused imports. General avoidance of common warnings. Suppression where needed. Removed dead code in configuration.
When merging new data into a PersistentEntity, JsonNodes of array types were deserialized into immutable Lists, but the list is later mutated if the source and target arrays are of different sizes. This commit ensures that an array is deserialized into a mutable list.
Original pull request: #371.
The usage of text/uri-list as media type was entirely broken and not even advertised in the reference docs anymore. It's now again supported for both to-one and to-many associations via Collections. Maps are rejected as they cannot be rendered as list of URIs correctly. Updated reference documentation accordingly.
Added a custom MapModel implementation of RepresentationModel as apparently using Maps with EntityModel does not unwrap the content properly due to [0].
[0] https://github.com/FasterXML/jackson-databind/issues/171
If no excerpt projection is exposed by the underlying ResourceMetadata, DefaultExcerptProjector now also properly declines its existence in ….hasExcerptProjection(…). Previously, it always indicated a presence as it improperly used a null check rather than calling Optional.isPresent().
Original pull request: #366.
