On JDK 17, trying to proxy Object doesn't work anymore. We now simply return the interceptor that would've been applied to the proxy directly and detect that properly in requests to extract the LastInvocationAware instance.
We now hand the already known property name (from the PropertyDescriptor) to the Property instance we create when inspecting classes for metadata. This avoids ambiguities stemming from the fact that Property assumes Java Bean style properties but Spring's BeanUtils also supporting Java Records style accessors. In special naming contexts like the one used in the test case, this can lead to properties considered "the same" as their accessor methods imply their name is the same.
We now eagerly convert all request parameters and path variables into their String representation using the MVC ConversionService to make sure we can use all formatting metadata available on the parameters.
We now allow explicit definition of a fallback collection element type on CollectionModel to be used in cases of an empty model, so that the RepresentationModelProcessor infrastructure can still reason about the element type and also invoke the processor for empty collection models.
Fixes#1590.
This commit introduces @NonComposite, an annotation to be used with collection or array typed @RequestParam handler method parameters. Using the annotation causes the rendering of request parameters to use the non-composite way of rendering URI template values (param=value1,value2) rather than the default, composite flavor of param=value1¶m=value2.
A bit of polish in TemplateVariable, which now also exposes a prepareAndEncode(Object) method that renders a given value according to the rules defined in the URI template spec for the particular variable type and state (composite VS. non-composite).
We now route calls to WebMvcLinkBuilder.linkTo(Method, Object[]) through the same infrastructure that linkTo(…) calls with a dummy method invocation are routed through. We construct a fake LastInvocationAware pointing to the given Method and parameters.
We now inspect the static request parameters declared in the actual request mapping and apply those values when building URIs pointing to those methods.
Original pull request: #1576.
Significant rewrite of UriTemplate to bring it up to level for template variables. We now additionally support:
* Composite values correctly
* Prefix values
* Multi-value template variables
* Path-style parameters
* Label expansion with dot-prefix
* Reserved expansion
Unit tests have been enriched with all examples given in the corresponding RFC [0]. Template variable types have been aligned with the terminology used in the RFC. Currently differently named types have been deprecated in favor of the new ones.
The commit slightly changes the behavior in two different aspects:
1. Query parameter values are now encoded as described in the RFC. Previously, special characters like comma (,) have not been percent encoded but now are. To create comma-separated values, expand an array of values instead of a prepared String. I.e. instead of expanding {?sort} with "foo,asc", expand it with [ "foo", "asc" ].
2. The aspect of variable optionality has been deprecated as it doesn't actually exist for template variables. This causes expansions that were previously rejected (e.g. ones using {foo} in paths) are now not rejected anymore. This is due to the way that the expansions are defined in the RFC.
[0] https://datatracker.ietf.org/doc/html/rfc6570
Embedded elements assembled through a HalModelBuilder expose those through a CollectionModel to make sure that the individual elements get grouped by their link relation and those potentially curied. To indicate a curie link needing to be added because of curied embeds, the serialization adds a magic link to the list of links of that CollectionModel. As the latter is unwrapped, an additiona _links block rendering a curie had been added to the representation rendering the JSON representation invalid, as it now contained two _links fields (the latter stemming from the actual links added to the HAL representation model).
We now tweak the CollectionModel returned to override ….add(Link) and rather route the magic link to the outer representation model, causing the inner one to never accumulate any links in the first place and thus not render an invalid _links.
Documentation for `HypermediaMappingInformation.getMediaTypes` expects to return a `List<MediaType>` which is not shown in the ref docs. Amend it with a proper parsing API as well as formatting.
This method is currently used in test cases only and the just introduced ability to rename property makes the method not reliably usable as the way it is named doesn't convey which name is to be used. It currently is the potentially renamed value. Moving to the actual property name as input creates stronger boundaries to assume a type backing the metadata, which we want to avoid.
