The fix for #2174 introduced a bug for our PUT handling of nested documents in case the target object's field value is null as it would only apply the nested value if all Optionals were present. This is, of course not the case.
Fixes#2264.
We now support using AggregateReference as type to bind request parameters taking URIs pointing to related aggregates. The default resolution will try to resolve the entire URI via UriToEntityConverter but one can also provide a function that can extract any part of the URI to be then resolved into either an identifier, aggregate instance or jMolecules Association against the ConversionService.
Fixes#2239.
Built on the the just introduced RepresentationModelAssembler implementations based on Slice in Spring HATEOAS and Spring Data Commons we now support returning a SlicedModel from the controller backing search resources ultimately triggering repository query methods.
The introduction triggered the refactoring to introduce RepresentationModelAssemblers (RMA) to remove the need for controllers inheriting from AbstractRepositoryController to access RepresentationModel assembly functionality. RMA acts as a facade for both Paged-/SlicedResourceAssembler as well as PersistentEntityResourceAssembler.
Fixes#2235.
We no pipe the Spring MVC ConversionService into the JSON Patch path binding. That usually is a FormattingConversionService at runtime and also supports the conversion of dates.
The ConversionServices is configured into the BindContext(Factory) we use for binding. The context then exposes the EvaluationContext set up with it.
Fixes#2233.
RepositoryRestConfiguration now allows to configure to return a response body for the deletion of item resources. The controller implementation follows the same patter we have already established for creation and updates: unless explicitly enabled or disabled we now consider the presence of an accept header as indicator of whether a response body should be rendered.
This could be a "breaking" change for clients having explicitly expected 204 until now even for requests with an Accept header. If that's an issue, those should either explicitly disable the setting, do not submit an Accept header or loosen their expectations to expect either 200 or 2xx as indicator of success in general.
Fixes#2225.
