Previously the backend identifier derived from the URI was set as identifier on the object to be created in a PUT request. However, in case a custom entity lookup is used, this is not the identifier but an arbitrary property pointed to through user defined code, mostly a method reference.
We now use the newly introduced MethodInvocationRecorder API in Spring Data Commons to be able to obtain the property that is supposed to be used and set that to the value calculated. This requires the entity type for which the custom lookup is configured to be non-final as the invocation recording is build on top of proxies.
Related tickets: DATACMNS-1449.
We're now able to correctly identify Map keys within JsonPatch paths so that e.g. people/Dave/name properly translates into a people['Dave'].name SpEL expression.
Streamlined the design of SpelPath to avoid duplicate parsing and properly express the difference between typed and untyped paths in the type hierarchy. Slightly refactored the type hierarchy so that only methods that make sense in either untyped or typed state appear on the instance returned (getLeafType(Class) was exposed on TypedSpelPath before, which was confusing).
Previiously, Spring HATEOAS pulled in the Spring WebMVC and apparently CorsRegistry, referenced from RepositoryRestConfiguration (unexpectedly) lives in that module. We now explicitly declare Spring WebMVC as dependency of Spring Data REST Core for the time being until [0] is resolved.
Related tickets: [0] spring-projects/spring-framework#22458
The lookup of the RequestMappingInfo in exposeEffectiveLookupPathKey(…) yields null for CORS preflight requests to resources that do not support OPTIONAL explicitly. We now guard against that to avoid a subsequent NullPointerException.
Previously we assumed lookup types to always result in String based values. We now loosen that constraint to also allow other scalar types, mostly targeting numeric types like long and integer.
We now properly only answer PersistentEntitiesResourceMappings.hasMappingsFor(…) with true if we find a non-null value in the cache. Previously, even a failed attempt to create some ResourceMapping would've caused ….hasMappingsFor(…) to indicate it PersistentEntitiesResourceMappings contains a mapping.
This lead to downstream NullPointerExceptions as ….getMetadataFor(…) was accessed without a null guard after ….hasMappingFor(…) returned true.
Aligned with general request attribute naming conventions and prefixed the one we now use with the class' name. Altered the local attribute name to EFFECTIVE_REPOSITORY_RESOURCE_LOOKUP_PATH.
Renamed the constant holding the name from …_KEY to …_ATTRIBUTE.
We now expose a partially resolved PathPattern to contain the explicit repository base path so that the subpaths can be grouped around the individual repositories exposed.
Related ticket: spring-projects/spring-boot#14872
