The default exposure of repository methods is now controlled via RepositoryRestConfiguration.setExposeRepositoryMethodsByDefault(…). If set to true (the default), a repository that is detected for exposure (which in turn can be controlled via RepositoryDetectionStrategy) will have default resources exposed in case of the mere presence of CRUD methods. Setting this to false will require you to explicitly annotated those methods with @RestResource.
Added RepositoryRestConfiguration.disableDefaultExposure() to set the RepositoryDetectionStategy to ANNOTATED and disables default method exposure in one go. That can be exposed via a Spring Boot configuration property downstream.
We now expose the constructor that takes a RelProvider in RepositoryResourceMappings so that clients can tweak the default relation names. Changed the order of constructor parameters of (previously) non-public constructors for consistency.
The RelProvider to be used with the mappings can now be configured via RepositoryRestConfiguration and defaults to the EvoInflector based one.
In case PersistentEntities exposes a managed type whose raw type currently doesn't have a PersistentEntity registered, the constructor of UriToEntityConverter ran into a NullPointerException.
We now explicitly check for null and skip those types.
Filed DATAREST-1021 for further improvements in the 3.0 time frame.
We now resolve the handler method argument type of an annotated repository event handler against the concrete handler type to make sure generics are resolved properly.
We now make sure that an @Order annotation on annotated event handler methods are considered and the methods are invoked in the defined order.
Non-annotation-based event handlers don't suffer from the same problem as they're ApplicationListener instances directly so that the container will enforce the correct ordering in case @Order is used or Ordered is implemented.
Some cleanup in EventHandlerMethod.
Original pull request: #248.
Fixed broken equals(…) in ProjectionDefinition. Switched to iterating over Map's entry set instead of the keys. Made UriAwareHttpServletRequest static.
Removed RepositoryRestConfiguration.addCorsMapping(…) as we currently don't have any other shortcut methods for configuration like this.
Tweaked the setup of (now Repository)CorsConfigurationAccessor to be created earlier so that we avoid recreation for every lookup. Introduced a NoOpStringValueResolver to be used by default so that we don't need to deal with the case of the resolver being null at the end of the call chain. Replaced constructor of RepositoryCorsConfigurationAccessor with corresponding Lombok annotation.
Updated reference documentation accordingly.
Original pull request: #233.
We now support CORS configuration mechanisms introduced in Spring 4.2. CORS can be configured on multiple levels: Repository interface, Repository REST controller and global level. Spring Data REST CORS configuration is isolated so Spring Web MVC'S CORS configuration does not apply to Spring Data REST resources.
Multiple configuration sources are merged so different aspects of CORS can be configured in separate locations.
@CrossOrigin
interface PersonRepository extends CrudRepository<Person, Long> {}
@RepositoryRestController
@RequestMapping("/person")
public class PersonController {
@CrossOrigin(maxAge = 3600)
@RequestMapping(method = RequestMethod.GET, "/xml/{id}", produces = MediaType.APPLICATION_XML_VALUE)
public Person retrieve(@PathVariable Long id) {
// ...
}
}
@Component
public class SpringDataRestCustomization extends RepositoryRestConfigurerAdapter {
@Override
public void configureRepositoryRestConfiguration(RepositoryRestConfiguration config) {
config.addCorsMapping("/person/**")
.allowedOrigins("http://domain2.com")
.allowedMethods("PUT", "DELETE")
.allowedHeaders("header1", "header2", "header3")
.exposedHeaders("header1", "header2")
.allowCredentials(false).maxAge(3600);
}
}
Previously our support for the HTTP DELETE method on item resources was requiring a repository's findOne(…) method to be available and exposed. However, the latter might not be desirable as the support of GET and HEAD requests for item resources depends on that.
We now changed that to only checking that a findOne(…) method is declared on the repository as the implementation of RepositoryEntityController.deleteItemResource(…) requires it to be present to be able to trigger the events that intercept deletes for a particular type.
We now correctly handle nested values by manually traversing the potentially nested property path, creating a PropertyAccessor for each nesting step considering the property access settings defined in the mapping metadata.
Changed the implementation of ValidationErrors to be based on AbstractBeanPropertyBindingResult to consider the nesting implemented in superclasses and using a PersistentPropertyAccessor to lookup the property values.
ValidatingRepositoryEventListener now uses this implementation if a PersistentEntity can be obtained for the type under consideration, falling back to a DirectFieldBindingResult otherwise.
Upgraded to JSONPath 1.1.0 as 0.9 is not supported with Spring 4.2 anymore. Tweaked integration tests due to changed semantics and internals of JSONPath >= 1.0.
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.
UriToEntityDeserializer now uses the RepositoryInvokerFactory to resolve entity instances directly to make sure potentially registered EntityLookup instances are considered for the lookup.
Spring Data REST now exposes an EntityLookup interface that allows to customize the property of an entity that shall be used to create item resource URIs. By default this mechanism uses the backend identifier and uses the repository's findOne(…) method.
The EntityLookup now exposes one method to return the property value to be used for URI generation as well as one method to obtain the entity instance from the very same raw identifier value. The EntityLookups are registered with both the SelfLinkProvider (for link creation) and the RepositoryInvoker (to obtain the entity instance).
RepositoryRestConfiguration now exposes a setRepositoryDetectionStrategy(…) to define which repositories should be detected for exposure by default. The default value for that will consider the repository interfaces visibility but also take the exported flag of @(Repository)RestResource into account. See all other options in RepositoryDetectionStrategies.
Tweaked the auto-registration of excerpt projections to avoid a circular dependency between configuration and resource mappings and moved it onto a BeanPostProcessor implementation.
We now explicitly drop parameters of type Pageable and Sort from being exposed as search resource parameters as they're added via the UriComponentsContributors anyway. This prevents "pageable" from showing up as parameter on Java 8 code compiled with -parameters. The latter adds naming information for the Pageable parameter and caused it showing up as is despite the fact that the UriComponentsContributor for Pageables exposes a dedicated syntax.
RepositoryRestConfiguration now exposes an option to enable enum value serialization and a nested configuration object to tweak the details.
If enabled, a Jackson serializer and deserializer is registered trying to resolve the enum values from the Spring Data REST resource bundle using the fully-qualified enum value name as key. If no explicitly configured value is configured a default translation is triggered that capitalizes the lowercased value name replacing the underscores with spaces (e.g. PAYMENT_EXPECTED -> Payment expected). This can be opted out of, of course.
On the parsing side the deserializer will also consult the resourcebundle and default translation but also accepting the enum name as is (also opt-outable).
Deprecated non-bean-style accessors for projection and metadata configuration on RepositoryRestConfiguration to make these options tweakable via Spring Boot application properties by default.
Moved the accessibility tweak to the EventHandlerMethod's constructor so that the modification only occurs at detection time. Polished unit test.
Original pull request: #187.
AnnotatedEventHandlerInvoker now uses the user class to detect handler methods on to make sure we don't accidentally find CGLib generated methods and thus invoke the handler multiple times later on.
Extended MethodFilter Methods.USER_METHODS to filter methods on CGLib proxy classes, too.
Added missing license header and Javadocs where necessary.
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.
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.
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.
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.
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.
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.
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.
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.
