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.
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.
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.
Instead of rendering an empty _embedded document for empty collections and pages we now explicitly trigger the creations of an EmbeddedWrapper for that empty, collection to preserve the collection's element type.
Tweaked ResourceProcessorHandlerMethodReturnValueHandler to invoke ResourceProcessor instances for those empty collections, too. PRHMRVH now checks the assignability of the raw resource type before analyzing the value type for a match.
RepositorySearchController now adds additional self links for the list of searches and a search execution.
Added an UnwrappingRepositoryInvokerFactory that transparently unwraps JDK 8 and Guava Optionals to make sure the consuming code works with values or plain nulls correctly.
We no correctly handle the customized association path if @RestResource is used on an association. Took the chance to refactor the resource mapping subsystem quite significantly to improve the handling of property mappings. Those had been externalized before.
RepositorySearchController now takes all request parameters as MultiValueMap to execute query methods. For parameters mapping to a managed resource we try to interpret the given parameter value as URI to actually trigger the URI-to-entity resolution through the newly registered UriToEntityConverter.
The latter is now registered with the default ConversionService registered so that it's
A lot of cleanups in RepositorySearchController. Removed some obsolete prints to the console to reduce log output during test execution.
Related ticket: DATACMNS-678.
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.
Significant overhaul of the JSONSchema support. This currently adds the following features:
- Complex nested types are exposed as descriptors with the properties pointing to them whenever necessary.
- Sets are treated as unique collections.
- Enums are handled as expected (enum values are listed).
- Renamings via @JsonProperty are considered.
- @JsonProperty(required = true) is considered and added to required properties.
- Date/time types (legacy Date, JSR-310, ThreeTenBP and Joda Time) are exposed with format "date-time".
- Objects with @JsonValue methods are considered to be rendered as String value.
- Formats and patterns can be manually configured on MetadataConfiguration.
TODOs:
- Implementation polish, JavaDoc
- Automatically inspect ObjectMapper to detect customizations made through Mixins and custom Serializers.
RepositoryEntityLinks now exposes methods to obtain links to all search resources and individual ones, including overloads to pre-expand Pageable and Sort parameters potentially contained in the method signature.
Search links now also contain a projection template variable if the type returned by the query method backing the search resource has projections registered.
To be sure to pick up domain type lookup customizations we now consistently use RepositoryMetadata instead of trying to be clever and re-detecting it via RepositoriesUtils.
Instead of using a DomainClassConverter directly we now use a raw ConversionService in UriToEntityConverter. This allos us to get rid off the bean definitions for UriToEntityConverter and DomainClassConverter. The population of the ConversionService is now taken care of by calling SpringDataWebConfiguration's addFormatter(…) in defaultConversionService().
Added unit tests for UriToEntityConverter.
Introduced a new property basePath on RepositoryRestConfiguration to allow a smooth migration to a new non-absolute base path configuration model to customize the URIs under which repository resources are exposed.
We're deprecating the current baseUri property as it previously supported absolute URIs. These are still supported but a warning is logged to ping users to move to the new base path based configuration.
We now use the base path to dynamically augment the mappings detected on our controllers with the path configured.
The annotation based event handling now relies on the type of the first method argument to determine the domain type the handler is interested in. Improved method invocation to not unnecessarily wrap exceptions thrown from them. Changed the test cases to throw a dedicated runtime exception to implicitly test that the
Renamed LinkSaveEvent to LinkedEntityEvent as it's not only used for save-events for entities. Make use of Methods' USER_METHOD filter. Moved the class into the util package. Removed the UUID converter as Spring's DefaultFormattingConversionService provides it out of the box.
Added missing license headers and JavaDoc. Deprecated Class<?> attributes on handling annotations.
Related pull request: #151.
The ProjectingMethodInterceptor now inspects collections and maps to apply projections to collection elements and map values. Test cases inspired by a contribution of Saulo Medeiros de Araujo.
Related pull request: #152.
We now use the newly introduced IdentifierAccessor API to make sure we benefit from store specific optimizations when looking up identifier values.
Added some user class lookups to make sure the projection and resource mapping lookup works if proxies types are handed around.
Introduced SupportedHttpMethods abstraction to be able to test the exposure of HTTp methods based on a CrudMethods instance only. Moved ResourceType to the core module.
Search resources are now considered sortable if they contain a Sort parameter. This is now reflected in MethodResourceMapping.isSortableResource().
Building on top of that, the RepositorySearchController now appends the sort template variable to links generated when listing search resources. It also now accepts resolved Sort instances to forward them to the query method execution. The controller now also uses DefaultedPageable so that request missing pagination information use the defaults configured for the PageableHandlerMethodArgumentResolver.
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.
Fixed ReflectionRepositoryInvokerIntegrationTests after some CRUD method detection changes that invalidated the test cases.
Related ticket: DATACMNS-539.
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
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.
