The previously static ObjectMapper used by JsonPatchPatchHandler now has to be provided by clients instantiating the handler.
Original pull request: #224.
ResourceProcessorInvoker suffered from Spring's ResolvableType.fromClass(…) using strong assignability checks between raw types and wildcarded right hand side types (i.e. Collection VS. Collection<?>). This has been reported [0] and fixed already but we have to switch to ResolvableType.fromRawClass(…) to get the desired assignment check behavior.
Tightened unit tests to verify the calls to the delegate handler, which had been disabled by accident and thus prevented us from detecting the issue with ResolvableType beforehand.
[0] https://jira.spring.io/browse/SPR-14648
PUT requests are supposed to replace the state of the resource with the request payload. However, Spring Data REST already handles a couple of domain object propoerties in a special way as theri values map to dedicated HTTP features: identifiers (URIs), last-modified dates (header) etc.
For users, it might be worthwhile to exclude other properties from being set by applying the payload, like properties that are completely under the control of the server, e.g. creation user and date, last modifying user etc. So far, users didn't have any means to exclude those properties as the handling of PUT requests treated every missing property of the payload as null value.
DomainObjectMerger now checks whether a property is actually writable before applying the implicit null value. The application can be disabled by annotation a property with @ReadOnlyProperty.
Previously, RepositoryRestMvcConfiguration declared a BeanPostProcessor instance in a non-static bean factory method. That required Spring to instantiate the configuration class and keeping it in uninitialized state, which could in turn cause issues downstream.
We now use a static method so that the container can obtain the bean instance without having to create an instance of the configuration class and thus deferring its initialization.
Spring 4.3's HeaderContentNegotiationStrategy switched from looking up the Accept header via the method returning a single (potentially comma separated) one to the method returning multiple headers in the first place. We now added an override of HttpServletRequestWrapper.getHeaders(…) to out custom adapter defaulting the media type to make sure the defaulting is visible and thus the right handler methods are looked up.
That previously missing caused the DelegatingHandlerMapping selecting the redirect to the HAL browser in case a request to the API root was sent without an accept header as the defaulting of the header to application/hal+json wasn't properly exposed anymore and the redirect to the browser — declaring a produces clause of text/html — was not causing any media type mismatch anymore.
Previously we handed the original entity to the AfterSaveEvent. This should work in most cases but actually repositories are allowed to return a completely different instance so that we now hand over the instance returned by the repository interaction to avoid potentially occurring issues.
We now use the APIs in place in Spring MVC to make sure we create proper redirects for requests that carry proxy headers so that the redirect target is still going through the proxy.
We now correctly handle nested values by manually traversing the potentially nested property path, creating a PropertyAccessor for each nesting step considering the property access settings defined in the mapping metadata.
A refactoring in the course of the 2.5 development dropped the application of explicit projection in case of excerpts being requested. This particularly applies to collection resources with explicit projection requests which need to get the explicit projection applied over the default excerpt projection potentially registered.
This is now fixed by the explicitly selected projection (if existing) always trumping the excerpt one.
Changed the implementation of ValidationErrors to be based on AbstractBeanPropertyBindingResult to consider the nesting implemented in superclasses and using a PersistentPropertyAccessor to lookup the property values.
ValidatingRepositoryEventListener now uses this implementation if a PersistentEntity can be obtained for the type under consideration, falling back to a DirectFieldBindingResult otherwise.
Until now, the controller handling a PUT request for an item resource defensively tried to set the identifier of the entity to update to guard against request payloads accidentally modifying the identifier of entities to be uploaded by using the raw identifier from the URI. Through the introduction of customized entity lookups this isn't necessarily the actual entity identifier anymore.
We now apply this defensive logic in the argument resolver for the incoming PersistentEntityResource where we have access to the object to update, can lookup the actual identifier directly and set it back after Jackson has applied the request body to the object to update.
Related tickets: DATAREST-724.
RepositoryPropertyReferenceController now uses a RepositoryInvoker instead of the ConversionService so that potentially applied customized entity lookups are considered during that lookup.
Extracted HttpHeadersPreparer to remove functionality and dependencies from the commons superclass of all Spring Data REST controllers in favor of a dedicated type.
Related tickets: DATAREST-724.
Upgraded to JSONPath 1.1.0 as 0.9 is not supported with Spring 4.2 anymore. Tweaked integration tests due to changed semantics and internals of JSONPath >= 1.0.
Extracted store specific tests into separate test modules to prevent classpath overlap between projects. Those tests are now executed in an "it" build profile to prevent the tests being packaged for distribution on release.
Use Map-based repositories and mapping contexts for test in the Core and WebMvc module.
Slightly changed the configuration API for lookup types on RepositoryRestConfiguration.
Related ticket: DATAREST-776.
Tweaked custom Jackson serialization to make sure nested entities are rendered as resources so that links to related resources can be collected on nested levels as well.
Extracted EmbeddedResourcesAssembler from PersistentEntityResourceAssembler so that embedded resources can also be build for nested entities. Extracted a ResourceProcessorInvoker from ResourceProcessorHandlerMethodReturnValueHandler to allow ResourceSupport instances created for nested entities get the ResourceProcessor instance registered for them invoked as well.
ProjectionDefinitionRegistrar now also allows the domain type of a repository being registered as excerpt, too.
Related tickets: DATAREST-776.
