We now don't expose the PersistentEntityJackson2Module as bean anymore to prevent global registration in case of a Boot setup. The HttpMessageConverters registered are now TypeConstrainedMappingJackson2HttpMessageConverters so that they only get used of the object to marshal is of type ResourceSupport.
This is mainly to prevent users from running into Java 6 incompatibility as the Evo library was accidentally compiled requiring Java 7 compatibility in version 1.1.
We now defensively invoke the ConversionService prior to the reflective invocation of the delete method as we have to assume the clients providing the id value in a raw form, i.e. as obtained from the request and thus most likely as String.
Related ticket: DATAREST-335.
Added explicit dependency to jackson-annotations as a library previously declared might pull in that one in a different version which might cause conflicts.
AssociationOmittingSerializerModifier previously dropped the writer fro a particular property if it couldn't find a PersistentProperty for the bean property. We now keep those writers to make sure that non-persistent, additional fields are written as well.
Related issues: https://github.com/spring-projects/spring-boot/issues/1190
Previously, if a persistent property was renamed using e.g. @JsonProperty, the lookup of the PersistentProperty failed as BeanPropertyWriter exposes the final (renamed) property name, not the internal one. We now defensively lookup the correct BeanPropertyDescriptor using the external name and use the corresponding internal one for the PersistentProperty lookup.
If a delete(…) method was overridden using the concrete id type, the check on invocation of course has to accommodate the concrete id type and not serializable only.
We previously erroneously attempted a to-entity-conversion by invoking findOne(…) and then handed that result to the delete(…) method which caused an IllegalArgumentException as the argument wasn't matching the parameter type. We now explicitly check for the concrete id type in the first place and even bypass any kind of parameter conversion.
During type matching in ResourcesProcessorWrapper we now accomodate the scenario that a Resources type is completely different than the Resources type to look for. This resulted in null being returned for the supertype generics lookup and this failed as the corresponding guard was missing.
Removed the wirings for PlatformTransactionManager and ValidationExceptionHandler from AbstractRepositoryRestController. Removed the latter entirely as it doesn't seem to be used anywhere anyway.
ResourceProcessorHandlerMethodReturnValueHandler now also invokes ResourceProcessors that are typed to Resources even if the value returned by the controller is a sub-type of it.
Also added test cases for the invocation of processors for projections.
The bean definition for annotatedHandlerBeanPostProcessor now is a static one so that it doesn't require the config class to be instantiated and populated, which caused the (too) eager initialization of all dependent beans.
Also we now leniently lookup all ResourceProcessor instances available in the context to prevent the lookup during config class preparation.
Ignore Neo4j tests now as they run into OutOfMemoryErrors.
The association handling in DomainObjectMerger is in place to allow the creation of resources using PUT that have non-optional associations. However, if the domain types that the request payload was unmarshalled into use default values - in particular empty collections to avoid nulls - the merger cannot really distinguish between the default set in the type versus an empty collection being submitted through the request.
As the usecase here is creation only we can safely ignore empty collections as submitting those doesn't make a difference anyway (no related items attached). By ignoring those, we fix the issue defaulted empty collections in the type definitions being considered as value to set.
We now defensively guard against URI templates submitted for related resources and expand the incoming URI string source to avoid URI.create(…) to fail.
Also, RepositoryPropertyReferenceController.loadPropertyValue(…) now also uses UriTemplate to guard against Uri templates provided for property references.
Fixed the request parameter binding of RepositorySearchController. executeSearchCompact(…). Changed returned value to Resources to be able to use the EMPTY_RESOURCES_LIST constant to indicate no actual results.
Original pull request: #139.
BaseUri now strips away the tail of a lookup path starting with {. An unencoded { must never appear in a URI but could accidentally be sent by a client forgetting to expand URI templates we return.
We need to proactively strip trailing slashes during base URI handling as even on a successful match (which previously left trailing slashes intact) this might subsequently on the resolving of the repository metadata when evaluating the left-over lookup path against the @RequestMapping methods (which keeps trailing slashes).
We now strip trailing and leading slashes from configured base URI to make sure the matching algorithm accommodates both lookup paths with and without trailing slashes.
Added a few more tests in shape of unit tests for BaseUri.
Introduced BaseUri value object being able to extract the lookup path within the Spring Data REST URI namespace from requests and plain lookup paths. This encapsulates the logic we previously had in RepositoryRestHandlerMapping but it is needed in the HandlerMethodArgumentResolver implementations as well to make sure they extract RepositoryMetadata correctly.
Refined the algorithm to detect the lookup path within the configured base URI, even if the base URI was defined in an absolute way. Also, solidified the implementation against URIs with trailing slashes.
In case @RestResource was used to customize the path a method resource was mapped to, we didn't correctly fall back to the method name as rel in case no rel was configured explicitly.
We now check for a rel being configured and fall back to the method name if we don't discover manual configuration.
