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.
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.
Major overhaul of mapping detection in RepositoryRestHandlerMapping. We now correctly map URIs if a base URI is configured via RepositoryRestConfiguration.
Additional tweaks needed for the back-port.
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
When parsing the id value from a URI we now pipe the obtained segment through Spring HATEOAS' UriTemplate to potentially remove optional tempalte variables. These variables might make it into the URI by clients that do not properly expanding URI templates before submitting requests.
This is effectively a backport of parts of the fix for DATAREST-155 in master.
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.
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.
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.
