Extracted store specific tests into separate test modules to prevent classpath overlap between projects. Those tests are now executed in an "it" build profile to prevent the tests being packaged for distribution on release.
Use Map-based repositories and mapping contexts for test in the Core and WebMvc module.
Slightly changed the configuration API for lookup types on RepositoryRestConfiguration.
Related ticket: DATAREST-776.
We now configure a proper output directory for Querydsl generated test classes. Previously we used the folder that's automatically picked up by the main compilation step which breaks subsequent compile runs if they're not run with a previous clean.
Upgraded to Groovy 2.4.4. Polished sample domain types and repositories. Removed obsolete format registration in test cases for schema creation. Keep inlined null checks to make sure the IDE doesn't create unnecessary can-be-null warnings.
Original pull request: #206.
Groovy-based objects inherit from GroovyObject. This brings along attributes that Spring Data REST may try to parse when generating metadata like JSON Schema. Also verify ALPS is supported.
We now exclude those artificial properties from being exposed in the schema as well as causing issues.
Original pull request: #206.
If Querydsl is on the classpath and the repository exposed implements QuerydslPredicateExecutor, we now register a component that customizes the RepositoryInvoker to route repository interactions for collection resource calls to the QuerydslPredicateExecutor.
The invocation gets enriched with a Predicate obtained from the request data. Bindings can be customized through the QuerydslBinderCustomizer interface implemented in a default method on the repository.
Tweaked the build to generate Querydsl meta-model classes for the MongoDB domain types.
Moved Spring Security specific dependencies to a dedicated profile in pom.xml. JavaDoc polishing. Removed assertions on the response message.
Original pull request: #171.
Added integration tests to verify Spring Data REST works with Spring Security as expected. Added method level security to sample repositories and verified HTTP responses to consider those.
Added some words on security configuration in the reference documentation. This is also demonstrated by some canonical samples found in [0].
Original pull request: #171.
[0] https://github.com/spring-projects/spring-data-examples/issues/21
Updated existing unit tests to use setBasePath. Added extra assertion to setBasePath to guard against sending in a URI with a protocol.
Original pull request: #178.
Extracted groups of dependencies into auto-activated profiles to make more visible which dependencies belong to which store. Simplified dependency setup where possible.
General polishing in the test cases added.
Added configuration for setting up an EmbeddedSolrServer instance within a temporary directory. We use a temporary test folder created by JUnit where we copy the required configuration to. The directory will also hold all index data and will be deleted afterwards.
Original pull request: #156.
This commit adds the support to expose additional resources that serve ALPS [0] resources to document the available state transitions and representations. The exposure is enabled by default and can be customized using the RepositoryRestConfiguration.metadataConfiguration() object.
Currently the set of descriptors exposed includes:
- A descriptor for the representation of the domain type. Linkable associations are represented as safe descriptors, ones that are not linked are semantic descriptors.
- Descriptors for each supported HTTP method for both the collection and item resources to indicate the ability to update, create, delete etc.
- Safe descriptors (e.g. to access the collection or item resource) get potentially available customizations (pagination, projections) attached through nested descriptors.
Documentation
An ALPS descriptor contains a doc attribute to carry semantic information for the end user or a potential client to display. The information can be described in two ways: the first one is the @Description annotation that captures the plain text information one wants to get listed. It is supported in @RepositoryRestResource, on query methods, projection interfaces and accessors etc.
The preferred approach however is to use a resource bundle rest-messages.properties. For each descriptor we will resolve a key starting with rest.description followed by a dot path into the resource. By default, doc attributes are only rendered if the resource bundle contains an entry for the relevant key. You can enforce displaying unresolved keys by configuring MetadataConfiguration.omitUnresolvableDescriptionKeys(…).
For representation descriptors and and the parameter list of query method descriptors we will display enum values by default as comma-separated list. The list is also available as message resolution argument, so that you can refer to the list in your description message via the {0} placeholder.
TODOs:
- Improve descriptors for associations (indicate ability to update etc.)
[0] ALPS - http://alps.io
We now support PATCH request with application/json-patch+json [0] and application/merge-patch+json media types. The support is based on some customized usage of the FGE JSON Patch library [2].
As we need to apply the patch to an existing object, we need translate the JSON Patch remove operation into a replace operation setting the value to null so that out entity processing component registers the request for removal. Same applies to requests for merge-patch+json.
From an implementation point of view the handling of the media type has moved from the controller into PersistentEntityResourceHandlerMethodArgumentResolver and its delegates, n particular JsonPatchHandler. The application of the changes to the existing domain object is handled in the newly introduced DomainObjectReader.
Related ticket: DATAREST-345.
[0] http://tools.ietf.org/html/rfc6902
[1] http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch
[2] https://github.com/fge/json-patch
Added explicit dependency to jackson-annotations as a library previously declared might pull in that one in a different version which might cause conflicts.
