Spring 5 has adopted a "no nulls" policy that causes certain methods to throw exceptions instead of returning a null. This updates Spring HATEOAS to handle it suitably.
Original pull request: #595.
We now prepend the given path (and query) handed to LinkBuilderSupport.slash(…) to make sure calls to UriComponentsBuilder.fromUriString(…) always considers the given value as path. Previously, a value containing a colon caused problems as the regex to detect scheme and port would accidentally match.
Related ticket: https://jira.spring.io/browse/DATAREST-1074
Our migration to the header handling for #509 (47cefe) unfortunately moved from starting with the servlet mapping for URI creation to using the full URI from the start.
This is now fixed by switching back by creating a UriComponentsBuilder from the current servlet mapping.
Related ticket: #509.
Removed the custom handling of proxy headers in ControllerLinkBuilder in favor of the behavior of UriComponentsBuilder in Spring Framework. The only thing that we keep custom is the handling of X-Forwarded-Ssl as it's rather non-standard.
Original pull request: #519.
If not all parameters are handed to a fake controller method invocation, the resulting link is now becoming a URI template. That means there are some tiny changes to the general behavior:
1. Missing required parts (like a path segment) are not rejected immediately but only if the resulting link is expanded itself.
2. Missing request parameters now appear in the resulting link, either in mandatory form (e.g. ?foo={foo}) or optionally (e.g. /{?foo}). To resolve these, the Link has to be expanded in turn.
We're now caching meta information about controller methods and their parameters more aggressively to avoid repeated lookups of such information via reflection. We're also keeping reference to proxy classes generated through CGlib around to avoid costly regeneration.
Note that the main culprit causing the drastic numbers reported in the original ticket stem from a problem in Spring's TypeDescriptor which triggers costly equals(…) comparisons on synthesized annotations [0].
Removed conditional reflective lookup of DefaultParameterNameDiscoverer as it's now present by definition.
[0] https://jira.spring.io/browse/SPR-14926
We now support composed annotations using @AliasFor such as @GetMapping that are mixed with @RequestMapping on type and method level.
@RequestMapping("type")
class MyController {
@GetMapping("method")
String method() {
…
}
}
Original pull request: #497.
ResourceProcessorInvoker suffered from Spring's ResolvableType.fromClass(…) using strong assignability checks between raw types and wildcarded right hand side types (i.e. Collection VS. Collection<?>). This has been reported [0] and fixed already but we have to switch to ResolvableType.fromRawClass(…) to get the desired assignment check behavior.
Tightened unit tests to verify the calls to the delegate handler, which had been disabled by accident and thus prevented us from detecting the issue with ResolvableType beforehand.
[0] https://jira.spring.io/browse/SPR-14648
Added a Spring 5 specific build profile and removed the references to AnnotationMethodHandlerAdapter which already had been deprecated in the latest Spring 3 in favor of RequestMappingHandlerAdapter.
Updated Spring build profiles in general.
The HalHandlerInstantiator now accepts an AutowireCapableBeanFactory to delegate component creation requests to for non pre-build serializers. This allows other serializers to benefit from Spring instantiation but at the same time use the dedicated serializers created as singletons.
Switched to a regular expression based split of links to make sure URIs that contain commas do not interfere with the rather simplified splitting algorithm we used before.
Changed invocations of constructors of the super class in Jackson Serializers to use JavaType instead of Class<?> as the constructor has been removed in some of the base classes in Jackson 2.7.
Upgraded to Jackson 2.5.5 along the way.
ControllerLinkBuilderFactory now forwards the source UriComponents to the ControllerLinkBuilder instead of turning it into a URI and a UriComponentsBuilder in turn.
Original pull request: #422.
DefaultCurieProvider now automatically adds the application URI (servlet mapping) in case the UriTemplate configured does not contain an absolute URI in the first place.
Re-introduced the simple isEmpty(…) methods in custom Jackson serializers as the more complex ones were introduced in Jackson 2.5 only. Removed the @Override annotations so that we could even compile against 2.4 if needed.
We now avoid calling URI.toString() to early to prevent the need to re-parse it and thus accidentally cause a double-encoding.
Original pull request: #382.
HalLinkListSerializer now tries to obtain a link title by looking up key _links.$rel.title for both the namespaced (curied) and local link relation if the former doesn't resolve into a message.
The curie rendering has been improved in the following ways:
- Resources now get their embeds inspected for namespaced keys and curies are added if at least one is found. This makes sure curies are also rendered if no namespaced link is registered.
- Nested resources skip curies entirely, assuming they have been added to the root correctly.
Had to change the order of _embedded and _links to make sure the embedded elements are processed first to tweak the links to indicate the need for curies.
DefaultCurieProvider now also takes a Map<String, UriTemplate> to expose multiple curies. The default curie to be used to expand unprefixed, non-IANA link relations has to be defined explicitly in case more than one curie is if given. If there's only one, that becomes the default, too.
Added missing override for isEmpty(…) that gets used by Jackson 2.6+ to prevent { templated : false } get rendered in HAL link representations.
Polished Javadoc on the way.
Switched from overrides of the deprecated (and removed in 2.6) isEmpty(T) to isEmpty(SerializerProvider, T). Switched from deprecated @JsonSerialize(include = …) to the dedicated @JsonInclude annotation.
