The usage of text/uri-list as media type was entirely broken and not even advertised in the reference docs anymore. It's now again supported for both to-one and to-many associations via Collections. Maps are rejected as they cannot be rendered as list of URIs correctly. Updated reference documentation accordingly.
Added a custom MapModel implementation of RepresentationModel as apparently using Maps with EntityModel does not unwrap the content properly due to [0].
[0] https://github.com/FasterXML/jackson-databind/issues/171
If no excerpt projection is exposed by the underlying ResourceMetadata, DefaultExcerptProjector now also properly declines its existence in ….hasExcerptProjection(…). Previously, it always indicated a presence as it improperly used a null check rather than calling Optional.isPresent().
Original pull request: #366.
Correct a regression regarding association links. Introduce several test cases to prove this situation is fixed regarding PUTs for association links.
Source of the bug: 554d6cb27b (diff-1d7c16fe1992fef13a47fa8ab8599718L317) flips the criteria from "not single" to "single" without checking for related impacts.
We now rely on the MessageResolver capabilities of Spring HATEOAS to benefit of the optimizations in resource bundle resolution. Tweaked a couple of tests to make sure they properly use the resolver resorting to the default message the MessageResourceResolvable exposes.
Deserializer customizations for related resources (deserializing an instance from a URI) are not applied to the creator properties Jackson uses to create an entity instance in the first place (see [0] for details). We work around this now by tweaking the property instances used for that in their origin ValueInstantiator via reflection until the bug gets fixed.
[0] https://github.com/FasterXML/jackson-databind/issues/2367
Removed the redeclaration of hasCorsConfigurationSource(…) in RepositoryRestHandlerMapping as it already inherits the one from BasePathAwareRestHandlerMapping.
We now enable CORS handling for all requests by overriding the newly introduced hasCorsConfigurationSource method. We cannot detect CORS configuration handling solely on the handler but require path headers to resolve repository interface mappings.
We now ship a module containing the HAL Explorer [0] as an alternative to the HAL Browser which seems to be mostly out of maintenance and the WebJar refers to a jQuery version with a CVE. The new module still contains some customization code that we had in place for the browser to customize the POST/PUT forms to use the JSON Schema exposed for the aggregates.
The HAL Browser extension is now deprecated in the form that its inclusion causes a warn log to recommend switching to the explorer. A couple of general coding improvements: package scope for controllers and handler methods. Better use of constants and newer request mapping annotations.
Tweaked the configuration of static resource handlers to resolve the implicit cyclic dependency between the browser/explorer and the WebMVC module by introducing a Spring Factories backed extension SPI.
[0] https://github.com/toedter/hal-explorer
Contrary to what's stated in the Javadoc of BackendIdConverter, BackendIdConverterHandlerMethodArgumentResolver now skips the invocation of ….fromRequestId(…) if no identifier path variable is found for the mapping of the method invoked.
MappedProperties now immediately drops non-writable properties when created for deserialization. Previously those properties would have to be annotated with @JsonProperty(access = Access.READ_ONLY) explicitly to avoid them being considered.
We now use a dedicated implementation of MessageSourceResolvable to avoid missing enum value translations actually causing exceptions. That also allows us to defer the calculation of the default (potentially translated in a default way).
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).
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.
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
MappedProperties now exposes a factory method that uses the Jackson introspector for serialization (instead of deserialization) which now also includes read-only properties. Previously, read-only ones were not considered as they are excluded from the metadata if it is looked up for deserialization.
