Previously, the SpEL expression created from JSON Patch path expressions were executed without double checking whether these paths actually exist on the target object in the first place. This check is now in place.
We now also catch SpelEvaluationException in the attempt to set a null value for an expression as Spring 5 now reports a failed attempt (e.g. if the target type is not nullable) using that type whereas Spring 4.3 threw a NullPointerException.
Fixed the setup of our custom ExceptionHandlerExceptionResolver to conclude with a call to afterPropertiesSet() to make sure it's properly initialized.
When a PATCH call using JSON Patch tried to append an item to an empty collection, it previously failed to look up the type to unmarshal the incoming payload to. We now inspect the declared types on the wrapped object's property to determine that type for append operations.
Also, an uninitialized collection is now initialized using Spring's CollectionFactory.
So far, we handed the plain instance deserialized from the request body to the repository to persist it. That caused issues in PUT for create scenarios where the URI contains the identifier to be used for the aggregate to create and identifier generation being used in the backend. In that case the identifier submitted was never considered and subsequent requests would've created new instances, effectively breaking the idempotent nature of PUT.
We now make sure the backend identifier derived from the resource is set on the aggregate instance about to be created, so that backend can either accept that situation (new entity + manually defined identifier) or reject it (in case it insists on identifier generation).
In case PersistentEntities exposes a managed type whose raw type currently doesn't have a PersistentEntity registered, the constructor of UriToEntityConverter ran into a NullPointerException.
We now explicitly check for null and skip those types.
Filed DATAREST-1021 for further improvements in the 3.0 time frame.
Previously, when a request was sending an Accept header of some arbitrary *+json, the request was routed through the controllers and might have ended up producing a PersistentEntityResource that was then mapped using an uncustomized Jackson ObjectMapper. That has caused a huge JSON object to be unfolded which is highly undesirable.
We now only answer JSON requests to repository resources that contain an Accept header with any of the explicit JSON media types we got registered.
We also now make sure MVC is bootstrapped property for integration tests through the inclusion of DelegatingWebMvcConfiguration.
