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.
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
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.
If a delete(…) method was overridden using the concrete id type, the check on invocation of course has to accommodate the concrete id type and not serializable only.
We previously erroneously attempted a to-entity-conversion by invoking findOne(…) and then handed that result to the delete(…) method which caused an IllegalArgumentException as the argument wasn't matching the parameter type. We now explicitly check for the concrete id type in the first place and even bypass any kind of parameter conversion.
The association handling in DomainObjectMerger is in place to allow the creation of resources using PUT that have non-optional associations. However, if the domain types that the request payload was unmarshalled into use default values - in particular empty collections to avoid nulls - the merger cannot really distinguish between the default set in the type versus an empty collection being submitted through the request.
As the usecase here is creation only we can safely ignore empty collections as submitting those doesn't make a difference anyway (no related items attached). By ignoring those, we fix the issue defaulted empty collections in the type definitions being considered as value to set.
This commit adds a mechanism to define excerpt projections to be rendered for exposed repositories. The main user facing mechanism is the addition of the excerptProjection attribute to @RepositoryRestResource. This attribute takes a type which has to be a projection interface (see DATAREST-221 for more information about the general mechanism).
If such a excerpt projection is in place, it will be used by default when rendering instances of the domain type in _embedded clauses or if it is related to.
class Person {
String name;
int age;
Person father;
Person mother;
Set<Person> siblings:
}
interface PersonExcerpt {
String getName();
}
If PersonExcerpt is now configured as excerpt projection for Person the collection resource for people will return:
{ _embedded : {
people : [{
name : "Some name",
_embedded : {
mother : { name : "…" },
father : { name : "…" },
siblings : [ … ]
},
_links : { self : { href : "…" }}
}, … ]
}
}
Here you can see how the age property is omitted when rendering a person in a collection. Also each person contains the excerpt projections of related resources and the links to them omitted. If you now follow the link to the item resource, you'll something like this:
{ name : "Some name",
age : 34,
_embedded : {
mother : { name : "…" },
father : { name : "…" },
siblings : [ … ]
},
_links : {
self : { href : "…" },
mother : { href : "…" },
father : { href : "…" },
siblings : { href : "…" }
}
}
Note, that age appears, as the representation is now rendered entirely. We also see the excerpts of related resource but also the links pointing to them in case you want to manage them.
In case @RestResource was used to customize the path a method resource was mapped to, we didn't correctly fall back to the method name as rel in case no rel was configured explicitly.
We now check for a rel being configured and fall back to the method name if we don't discover manual configuration.
RepositorRestConfiguration now has a ….useHalAsDefaultJsonMediaType() which defaults to true. Configuring this to false allows to still use HAL as default media type in case no Accept header is set or it is set to */*. The flag decides what to return when an Accept header is set to application/json.
Major overhaul of mapping detection in RepositoryRestHandlerMapping. We now correctly map URIs if a base URI is configured via RepositoryRestConfiguration.
Introduced BackendIdConverter SPI to be able to register custom components that will be used during URI construction and URI parsing to determine the actual backend identifier.
To register a custom BackendIdConverter simply declare a bean definition for it in the ApplicationContext. The Spring Data REST URI creation infrastructure (RepositoryEntityLinks in particular) will pick it up transparently.
PropertyAccessingMethodInterceptor now ignores Object methods and forwards them to the proxy target. ProxyProjectionFactory now correctly sets up the SpEL root object for reference in expression on accessors.
Previously we only handled URIs to associations on the root object level as the mapping information for potentially nested embeddables were not accessible via the Repositories instance. This is now fixed by switching to the newly introduced PersistentEntities.
Related tickets: DATACMNS-457, DATACMNS-458, DATAJPA-484.
We now register a RepositoryRelProvider that hadn't been exported before so that clients using a RelProvider will automatically see potentially customized rels for repositories.
Changed RepositoryRelProvider to lazily depend on the ResourceMappings as will be requested eagerly for injection into the configuration class itself.
This commit introduces support to access resources via projections, which means naming a dedicated set of properties of the entity to be exposed and being able to refer to that set through a request parameter.
## General usage
Projections are defined as interfaces that mimic the properties of the domain class to be exported:
@Projection(types = Customer.class, name = "summary")
interface Summary {
String getFirstname();
String getLastname();
AddressSummary getAddress();
}
interface AddressSummary() {
String getZipCode();
}
The projection interface can be annotated with @Projection to be auto-discovered. We scan all packages in which we find domain types to be exported for projection types and auto-register them. For manual registration, use RepositoryRestConfiguration.projectionDefinitionConfiguration().addProjection(…) and manually register them.
If a projection is registered for a given type, this will be indicated via a "projection" template variable in the URI pointing to resources with projections. The name of the variable can also be configured on ProjectionDefinitionConfiguration.
## Internals
The projection interfaces are consider bean property delegates by default. This means, that for the above interfaces we will lookup the firstname, lastname and address property of the projection target. In the case of address we re-project the result of the proxy target invocation with a sub-projection onto AddressSummary.
For more advanced use-cases you can annotate a method of the projection interface with @Value and use a SpEL expression to invoke further functionality and return that to be rendered:
interface MyProjection {
@Value("#{@myBean.someMethod(target)}")
SubProjection getValue();
}
This projection would call the someMethod(…) method on a Spring bean named myBean handing the proxy target to the method. The result will be projected in turn onto a type called SubProjection.
As the projection objects are exposed to Jackson as is, they can be annotated with Jackson annotations to further customize the representation.
Refactored PersistentEntityJackson2Module to move a lot of the customization logic into Bean(De)SerializerModifiers. Those allow to modify the Jackson metadata for a given type programmatically so that we can register the appropriate (de)serializers for associations.
On the serializing side of things this allows us to easily turn associations into links and simply delegate to object serialization as the delegation will simply ignore the association properties as they have been dropped using the modifier. This solves the advanced requirements of DATAREST-117 nicely as all non-association properties are serialized using standard Jackson means so that all customizations apply.
On the deserialization side, we now support URIs as values for association properties to be able to submit references for non-optional associations on creation.
Related issue: DATAREST-117.
Code polishing in DomainObjectMerger and related test cases. Fixed the related test cases. Cleanups in ControllerUtils to remove unneeded constants and make sure we really render no content for empty responses.
Refactorings in controller classes to reduce code duplication. We now do not allow POST requests for partial updates to property reference resources anymore but require the usage of PATCH.
Tweaked test helper methods to correctly implement basic interaction patterns.
Related pull request: #127.
Refactored the way the general support for an HTTP method for the resource exported. The decision is implemented in RootResourceInformation (formerly RepositoryRestRequest). Removed request specific information from that class and introduced a HandlerMethodArgumentResolver to be able to inject HttpMethod instance into controller methods (filed https://jira.springsource.org/browse/SPR-11425 to get that support into Spring Framework itself).
Generally moved away from throwing NoSuchMethodExceptions and correctly expose HttpRequestMethodNotSupportedException instead to make sure Spring MVC renders the appropriate allowed methods if possible.
Removed RepositoryInvokerHandlerMethodArgumentResolver as a RepositoryInvoker can be obtained from the RootResourceInformation where necessary.
Related pull request: #125.
CrudRepositoryInvoker now detects re-declared CRUD methods and falls back to reflection invocation if the re-declaration is detected.
Inspired by PR #126 by Nick Weedon but avoiding the introduction of a dependency to Spring Security by using a more precise testing approach.
Original pull request: #126.
ValidatingRepositoryEntityListener previous referred to a Repositories instance which causes a circular reference on initialization after some changes in Spring Data Commons Repositories.
Major cleanups in the ValidatingRepositoryEntityListener implementation.
Generally polished implementation and test cases for Greg's contribution.
Re-ordered parameters in ControllerUtils' helper methods for consistency.
Use Spring's CollectionFactory to create a suitable collection for the handled properties in the first place to avoid unnecessary conversion later on.
Removed duplication in test cases. Polished JavaDoc in UriListHttpMessageConverter and moved to a Scanner based implementation to read the request body.
Adapted to latest changes in Spring HATEOAS. Reactivated ResourceStringUtilsTests.
Related pull requests: #128, #86.
@RepositoryRestResource exposes more detailed attributes tailored to the use case of exposing a repository. @RestResource is still recognized on repository interfaces but we now issue a warning and indicate the new annotation to be used.
Introduced a minimal ResourceDescription interface and let @Description be used within @RestResource and @RepositoryRestResource. We now generate default resource bundle keys and resolve them against a "rest-messages" resource bundle by default. JsonSchema converter now uses the rendered descriptions for schema descriptions.
If the resource exposed for a domain or repository type is considered a paging resource we now return a templated URI. Introduced ResourceMapping.isPagingResource() to allow clients to find out about whether the resource is actually capable of pagination. Adapted implementations to inspect the findAll(…) method as well as the search methods for a Pageable parameter.
Tweaked pom.xml to create correct classpaths if the IDE uses direct workspace project references.
MethodResourceMapping now exposes the parameters a query method expects. The RepositorySearchController the uses these to append the
Upgraded to Spring Data Commons 1.7.0.BUILD-SNAPSHOT.
This commit introduces support for HAL rendering and making it the default rendering option. The configuration now registers an additional MappingJackson2HttpMessageConverter with the according HAL modules registered and makes this the default JSON renderer if the default media type is configured to HAL (which it is by default). To change this, set RepositoryRestConfiguration.setDefaultMediaType(…) back to application/json.
Refactored the PersistentEntityJackson2Module to turn the PersistentEntityResource into it's correct shape (turning associations into links) and the delegate to the default rendering, so that the HAL customizations provided by Spring HATEOAS can kick in. Adapted test cases to the change in default representation format.
Upgraded to Jackson 2.3.0, Spring 3.2.6 and Spring HATEOAS 0.9.0.BUILD-SNAPSHOT. Upgraded to Gradle 1.10.
Removed the attempt to add a link to the response for non-associations. Switched to the usage of Simple(Property|Association)Handlers for simplified generics.
