Simplified new RepositoryMappings infrastructure. Integrated EvoInflectionRelProvider to build collection resource rels. Bumped version number to 2.0 as we're going to break backwards compatibility with the next release to straighten out the rel construction and mapping.
Additional changes include:
* Re-wrote the monolithic Controller into separate controller classes that have a more narrow focus.
* Implemented common functionality as a `HandlerMethodArgumentResolver` rather than as a helper method in a controller class.
* Re-implemented JSONP functionality as an HttpMessageConverter rather than inline within a controller class.
* Updated to Jackson 2 for all JSON handling.
* By relying on spring-data-commons, spring-data-rest now handles all supported Repository types: JPA, MongoDB, and GemFire.
Added support for MongoDB and GemFire repositories by relying on spring-data-commons to provide the metadata rather than maintaining internal metadata information that is store-specific.
Replaced Spock spec tests with JMock unit and integration tests. Started integrating Jetty 8 into the testing so MVC testing can be done against a live server.
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.
There were some issues with how results were being displayed in searches versus entity lists. This code changes the way all results are displayed by offereing several options for output. The default is to inline the entity in the response and page the results (defaults to 20). If the UA sends an `Accept` header of `application/x-spring-data-compact+json` or `text/uri-list`, however, SD REST will output a compact list of only links and will not inline the entities.
The method of output was completely rewritten to use HttpMessageConverters exclusively. Views and the subsequent ContentNegotiatingViewResolver machinery have been elimintated. This should make it easier to embed inside an existing Spring MVC application. This is also easily extendable so the user can plug in their own set of HttpMessageConverters for any output format they like (JAXB, Atom/XML, etc...).
Also added was JSONPE support. By setting the `jsonpParamName` property on the `RepositoryRestConfiguration` customization class, the user can change the default JSONP param name of `callback`. There's also a `jsonpOnErrParamName` property on that configuration (defaults to `null`) that will allow you to capture errors using JSONP. Normally this would not be possible using script element injection, but the REST controller changes the status code to 200 and pass your javascript function the actual response code and wraps the error as the second parameter.
