Since `ResourceSupport` has direct access to the list of links, no need to build up an intermedia `List` and then filter on it. Simply filter on the internal list of links. Also did some minor polishing.
Moved RenderSingleLinks enum into HalConfiguration. Simplified HalConfiguration setup by moving the default into the class. The lookup of a user-provided HalConfiguration is now handled on the bean name level to avoid premature initialization of a potentially defined bean. Formatting.
Original pull request: #295
Related issues: #291
We now expose HalConfiguration to be defined as Spring bean in user configuration to control certain aspects of the HAL rendering. Initially we allow to control whether links shall always be rendered as collection. If no user-provided bean is available, we register a default instance.
Original pull request: #295
Related issues: #291
Added application/hal+json;charset=UTF-8 to the media types enum. Traverson now configures all HAL flavors to be supported by the registered HAL-specific HttpMessageConverter.
Removed nullability of media type in JsonPathLinkDiscoverer. This requires subclasses that want to support all media types to explicitly configure MediaType.ALL.
Heavily inspired by the PR submitted by @drummond but very significantly rewritten.
Adds many additional attributes defined in RFC5988 and verifies they work properly in the neutral representation of Link while also being rendered properly in the HAL module.
Related tickets: #100, #417, #235
Previous pull requests: #240, #238, #223, #79
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.
