We now skip the registration of the default media type if no hypermedia types are activated in the first place. We previously assumed there'd be at least one media type configuration registered.
If a parameter array is given to MethodLinkBuilderFactory.linkTo(…) methods, we now verify its correct length in correspondence to the method given. If no parameters are given at all, we automatically create a parameter value array of the required length.
We now explicitly set the optimize flag on the ProxyFactory for class based proxies used to create dummy invocation proxies. Still needs the upgrade to Spring Framework 5.3.11 (spring-projects/spring-framework#27439, #1647) to create full effect.
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.
Handler method parameters annotated with @RequestParam(defaultValue = …) are implicitly not required and thus should still be advertised in the URI templated generated. Previously it was necessary to explicitly set @RequestParam(required = …) to false.
Original pull request: #1511.
Related ticket: #331.
We pulled up the parameter name lookup for request parameters to avoid repeated lookups but unfortunately missed that the lookup will fail e.g. for @RequestParam Map<…> as we now strictly tried to find a request parameter name that doesn't actually exist in this case.
We now also eagerly map the keys for the _embedded map in a HAL response to Strings to make sure they work properly when sorting of map keys is activated for the Jackson ObjectMapper.
@EnableHypermediaSupport(types = {}) was not working anymore as the Comparator implementation working with the selected types rejected an empty list. We now do not reject that anymore to enable applications that solely work with third party media types.
Prior to this commit, the map of links to be rendered would key by LinkRelation. Unfortunately, Jackson requires `Map` keys to implement `Comparable` in case `SerializationFeature.ORDER_MAP_ENTRIES_BY_KEYS` is enabled. We now use the link relation's value as key right aways as Strings are comparable out of the box.
Switched to use Spring's MultiValueMap to avoid having to deal with the value list initialization ourselves.
We now check whether we could really load `@Range`, which is only available in Hibernate Validator. An arrangement in which the Validation API JAR is on the classpath but not Hibernate Validator would let us end up with the relevant instance being `null` and need a check for before being handed into code that requires the type to not be `null`.
