* Added a configuration property to `RepositoryRestConfiguration` for deployments behind a proxy which do not know the external URL to use as the baseUri for links.
* Changed the way the baseUri is injected into the controller by introducing a `BaseUriMethodArgumentResolver` to inject the proper baseUri (either the one from the configuration, or the one from the request if that's not specified).
Using ResourceProcessors again now as some kind of middle ground between the two former design ideas. We use a value returning callback now to allow manipulating the ResourceSupport instance in its entirety. This enables implementations to be either mutable or immutable. The ResourceProcessor interface is a little less flexible than in the first iteration as we require the same type to be returned.
ResourceEnricherInvokingHandlerAdapter now has a copy constructor to
allow setting it up from a default RequestMappingHandlerAdapter. The
reason we introduce this is that WebMvcConfigurationSupport unfortunately
does not allow customizing the handler adapter class to be used as its
instantiations is buried in a method with more setup code. With the copy
constructor introduced one can simply take the configured instance
WebMvcConfigurationSupport provides and pipe it into the custom
ResourceEnricherInvokingHandlerAdapter.
Dropped usage of separate interface for ResourceProcessor and
ResourcesProcessor and go with general ResourceEnricher interface. The
custom HandlerAdapter now also invokes enrichers for Resources' content
elements before invoking enrichers for the Resources instance itself.
This commit implements the components described in DATAREST-40. The core
of it is the ResourceProcessingHandlerMethodReturnValueHandler. It gets
ResourceProcessor and ResourcesProcessor instances handed into its
constructor and selects the ones that need to be invoked in the calls to
handleReturnValue(…). In this process it does a variety of generics
checks to ensure only the correct post-processors. To do so it inspects
the controller method's return type, the object value type as well as
the returned value potentially.
Assume we have a specialized Resource type
StringResource extends Resource<String>. Beyond that we have a
ResourceProcessor<Resource<String>> registered. Here's the decision
matrix:
Return type Returned type What get's used?
Resource<?> Resource<String> object value inspected (Resource.getContent())
Resource<String> Resource<String> method return type
Resource<String> StringResource object value type as it's more specialized
StringResource StringResource method return type
Resource<?> Resource<Long> no invocation, object value doesn't match
Resource<? extends Number> Resource<Long> no invocation, object value doesn't match
Resource<Long> Resource<Long> no invocation, object value doesn't match
This works exactly the same for Resources returned. We peek into the
collection returned by getContent() in case return value inspection is
needed for type matches. If the collection is empty we don't match. The
same applies to null values returned.
The second component added is the ResourcePostProcessorInvokingHandlerAdapter
which customizes the setup of a RequestMappingHandlerAdapter by fronting
the current configuration with the
ResourceProcessingHandlerMethodReturnValueHandler to let it intercept
the handling and potentially call the post-processors.
Upgraded to snapshots of Spring Data Commons until we get to the next
release and added Mockito as dependency.
