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
Upgraded to Spring 4.3.3 snapshots for now to benefit from fixes in ResolvableType [0]. Upgraded to Jackson 2.7.4 on the way and added a build profile for released Spring 5 versions.
[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.
