Spring 4.0.9 does not include the constants for HTTP headers whose usage was introduced in 46b08. Reverted to use the String equivalents.
Original pull request: #184.
Improved example headers to not expose we're referring to test code. Used inline code instead of bold for technical terms (HTTP methods, HTML attributes etc.).
Original pull request: #184.
We now override canRead(Type, Class<?>, MediaType) and tweak some of the delegate to reflect the patch in Spring HATEOAS spring-hateoas/#360 but without having to upgrade to the new version.
Instead of using the PersistentEntityResource to obtain the ETag we now calculate headers based on the domain object and PersistentEntity upfront. This prevents the failure of trying to read the ETag from a potentially projected proxy.
Excerpt projections defined in @RepositoryRestResource had to be discoverable (i.e. located in a sub-package of the domain type). RepositoryRestMvcConfiguration now uses an newly introduced constructor of ProjectionDefinitionConfiguration that automatically registers all projects in the given ResourceMappings.
The preparation of the JsonNode that we map onto the domain object now correctly looks up fields by their mapped names. Previously we accidentally checked the incoming JSON for fields with raw unmapped property names with caused fields invalid detected or not detected if a custom Jackson naming strategy was in place.
We now support augmenting elements of a collection resource by using POST which previously only worked with PATCH requests. Took the chance to clean up RepositoryPropertyReferenceController by quite a bit and refactor functionality to discover the supported HTTP methods for a PersistentProperty into RootResourceInformation.
Previously, RepositoryRestMvcConfiguration exposed its two ResourceSupportHttpMessageConverter beans as MappingJackson2HttpMessageConverters. This made it impossible for Spring Boot support for conditional beans to identify that they were type-constrained and, therefore, were not a suitable replacement for a general-purpose Mapping Jackson2HttpMessageConverter bean.
This commit updates RepositoryRestMvcConfiguration to expose both of its Jackson message converters as TypeConstrinaedMappingJackson2HttpMessageConverter instances. This will also Spring Boot to identify that their converters are type-constrained so that it can continue to auto-configure its general purpose converter. This is important as it allows Boot to provide a converter that honors the user’s configuration rather than Spring MVC’s default converter which does not. See spring-projects/spring-boot#2914 for details.
Original pull request: #174.
Before replacing the remove operation with a custom one that nulls out the object, we check whether the JSON Pointer points to an array element. If that's the case we skip the replacement and proceed.
We now also handle HttpRequestMethodNotSupportedException and UnsatisfiedServletRequestParameterException and traverse the chain before eventually rejecting the mapping attempt with the last exception found.
Related tickets: DATAREST-409.
Previously the link pointing to representation descriptors of associations neither pointed to the ALPS controller nor to the representation descriptor.
Added an UnwrappingRepositoryInvokerFactory that transparently unwraps JDK 8 and Guava Optionals to make sure the consuming code works with values or plain nulls correctly.
RepositorySearchesResource now exposes the domain type for whom the searches are listed to allow implementations of ResourceProcessor add links by type more easily.
A lot of cleanups in RepositoryRestExceptionHandler: prefer static methods where possible. Removed delegates where only one client was calling the method. Consistent argument ordering with optional (nullable) parameters last.
Silenced logging in unit tests for RepositoryRestExceptionHandler.
We now inspect If-None-Match and If-Modified-Since headers on GET requests to item resources and return 304 Not Modified if appropriate.
Disable rendering of version property in Jackson serializer as it's reflected in the ETag.
Related tickets: DATAREST-160, DATAREST-471.
We now treat embedded projections as Resource instances and equip them with a self link. This should also allow to register ResourceProcessor instances for projection types to even add projection specific links if necessary.
Also removed the explicit removal of the association link in case a projection is rendered for an association.
We now explicitly activate the resolution of lazy-loading proxies on Hibernate 4 to make sure not already populated lazy-loading proxies are actively resolved.
IncomingRequest.isJsonPatchRequest()/….isJsonMergePatchRequest() previously did a hard equals comparison to the media type discovered in the request. This fails if the request's media type contains parameters (e.g. the charset).
We now rather use MediaType.isCompatibleWith(…) to compare the media types more leniently.
Renamed test case to match conventions so that the Maven build actually executes them.
The ALPS document rendered now links to the JSON Schema document from within the core representation descriptor to allow clients to obtain more detailed information about the payloads to send and receive.
During our custom JSON handling on PUT requests, we previously piped all JSON objects through code that expected that one to be mapped to a PersistentEntity. This fails for JSON objects that basically represent maps.
We now skip that code paths for non-entity properties.
Moved decision logic on whether to return response bodies int RepositoryRestConfig to ease testability of the controller. Added more unit tests and simplified the controller integration tests accordingly. Had to deactivate some Cassandra related tests as they don't seem to handle nulling of properties correctly.
Changed configuration to rely on the presence of the Accept header by default. Deprecated parameterless isReturnBodyFor…(…) methods in favor of the ones taking the Accept header to avoid the null checks on the calling side.
Polished JavaDoc for the isReturnBodyOn(Create|Update) methods. Polished formatting in RepositoryEntityController.
Original pull request: #167.
By default, whether to return response bodies for PUT and POST is determined by the presence of an Accept header, unless explicitly activated or deactivated in RepositoryRestConfiguration.
Original pull request: #167.
In case a manually implemented controller is registered to add a dedicated media type for a Spring Data REST resource (e.g. an HTML representation for item resources) we now continue to serve JSON in case the request indicates it wants to see it.
Previously this didn't work as the manually implemented controller method was detected to partially match (only the produces-clause not matching) and thus an exception being thrown from the HandlerMapping lookup. This caused the HandlerMapping registered for repositories not being considered at all.
This is now fixed by hiding the HandlerMapping instances we register behind a DelegatingHandlerMapping that continues to try delegates even in a case of an exception being caused in a particular resolution attempt. Should all resolution attempts fail, we then throw the original exception if one occurred in the first place.
