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.
AssociationOmittingSerializerModifier previously dropped the writer fro a particular property if it couldn't find a PersistentProperty for the bean property. We now keep those writers to make sure that non-persistent, additional fields are written as well.
Related issues: https://github.com/spring-projects/spring-boot/issues/1190
Previously, if a persistent property was renamed using e.g. @JsonProperty, the lookup of the PersistentProperty failed as BeanPropertyWriter exposes the final (renamed) property name, not the internal one. We now defensively lookup the correct BeanPropertyDescriptor using the external name and use the corresponding internal one for the PersistentProperty lookup.
During type matching in ResourcesProcessorWrapper we now accomodate the scenario that a Resources type is completely different than the Resources type to look for. This resulted in null being returned for the supertype generics lookup and this failed as the corresponding guard was missing.
Removed the wirings for PlatformTransactionManager and ValidationExceptionHandler from AbstractRepositoryRestController. Removed the latter entirely as it doesn't seem to be used anywhere anyway.
ResourceProcessorHandlerMethodReturnValueHandler now also invokes ResourceProcessors that are typed to Resources even if the value returned by the controller is a sub-type of it.
Also added test cases for the invocation of processors for projections.
The bean definition for annotatedHandlerBeanPostProcessor now is a static one so that it doesn't require the config class to be instantiated and populated, which caused the (too) eager initialization of all dependent beans.
Also we now leniently lookup all ResourceProcessor instances available in the context to prevent the lookup during config class preparation.
Ignore Neo4j tests now as they run into OutOfMemoryErrors.
We now defensively guard against URI templates submitted for related resources and expand the incoming URI string source to avoid URI.create(…) to fail.
Also, RepositoryPropertyReferenceController.loadPropertyValue(…) now also uses UriTemplate to guard against Uri templates provided for property references.
Fixed the request parameter binding of RepositorySearchController. executeSearchCompact(…). Changed returned value to Resources to be able to use the EMPTY_RESOURCES_LIST constant to indicate no actual results.
Original pull request: #139.
BaseUri now strips away the tail of a lookup path starting with {. An unencoded { must never appear in a URI but could accidentally be sent by a client forgetting to expand URI templates we return.
We need to proactively strip trailing slashes during base URI handling as even on a successful match (which previously left trailing slashes intact) this might subsequently on the resolving of the repository metadata when evaluating the left-over lookup path against the @RequestMapping methods (which keeps trailing slashes).
We now strip trailing and leading slashes from configured base URI to make sure the matching algorithm accommodates both lookup paths with and without trailing slashes.
Added a few more tests in shape of unit tests for BaseUri.
Introduced BaseUri value object being able to extract the lookup path within the Spring Data REST URI namespace from requests and plain lookup paths. This encapsulates the logic we previously had in RepositoryRestHandlerMapping but it is needed in the HandlerMethodArgumentResolver implementations as well to make sure they extract RepositoryMetadata correctly.
Refined the algorithm to detect the lookup path within the configured base URI, even if the base URI was defined in an absolute way. Also, solidified the implementation against URIs with trailing slashes.
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.
In case a base URI is an absolute one, we now rely on only the base URI as foundation for all links created. Relative base URIs are considered are considered an amendment to the current server base up until the servlet mapping. The latter allows to create a dedicated URI namespace for Spring Data REST exposed resources.
Major overhaul of mapping detection in RepositoryRestHandlerMapping. We now correctly map URIs if a base URI is configured via RepositoryRestConfiguration.
Removed custom subclass to use @EnableHypermediaSupport as this was effectively a workaround for SPR-11251, fixed in Spring 3.2.7.
Move away from autowiring all MappingContexts into the configuration as this will require the instances to be created when the configuration class is prepared. We now rather inspect the BeanFactory on access of persistentEntities().
Added StringTo(Distance|Point)Converter implementations to be able to submit Distances and Points via URIs. See the JavaDoc of those classes for more details.
RepositoryRestMvcConfiguration now also registers the GeoModule provided by Spring Data Commons with the ObjectMapper registered for our custom HttpMessageConverters.
We now explicitly set a base backage in the Neo4jConfiguration to make sure, the domain classes get added to the MappingContext upfront. Filed DATAGRAPH-448 [0] for some reasonable defaulting going forward.
[0] https://jira.spring.io/browse/DATAGRAPH-448
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.
The JIRA issue asserts that PUT wasn't properly storing things. But now it does. A partial record causes all other fields to get nulled out. Added a test case to confirm this.
Original pull request: #134.
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.
Prevent NullPointerException in case we don't find a requested projection. We simply return the source object if so. Added unit tests to make sure we don't introduce a regression.
Removed NoOpProjector from production code as it is only needed in test cases anyway.
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.
AssociationOmittingSerializerModifier not correctly handles transient properties, which means it's handling null PersistentProperties correctly.
Also, AbstractRepositoryRestController.handleNotReadable(…) is not bound to HttpMessageNotWritableException anymore which caused the former errors to be masked by a Spring MVC exception claiming about the exception handler method not being invokable correctly.
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.
Simplified annotation detection. Added ignore guards to the association handling as well, so that associations not pointing to a repository managed resource can be ignored from being rendered as well.
Original pull request: #135.
Wrote test cases to verify it handles class level and attribute level annotations to ignore properties when rendering PersistentEntityResources.
Original pull request: #135.
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.
Links are a read-only and basically have to be ignored during any inputs. This required removing the deserializer from PersistentEntityJackson2Module. This will cause the object mapping to fail as it doesn't know about the links property in the request body. Instead of requiring that every entity apply the necessary annotation, the mapper is configured to not fail on non-existent attributes. This allowed all the tests to pass while properly handling PUT operations.
Original pull request: #130.
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.
Properties with null values properly get rendered in JSON outputs. This was fixed some time ago. Added test case to prove it.
Original pull request: #132.
