Forwarding headers handling is now centralized in ForwardedHeaderFilter and removed from ServletUriComponentsBuilder. We need to filter requests containing forwarding with ForwardedHeaderFilter.
Adapted RepositoryRestMvcConfiguration to now create a shared fallback ObjectMapper and avoid to register it as Spring Bean. Adapted test cases that previously were relying on such a bean being present.
Adapted test cases to verify on the correct ALPS document structure (see spring-projects/spring-hateoas#665).
Instead of replacing the HAL Browser's browser.html, take the existing one and alter it inside the build job. This ensures that future updates don't break so horribly.
Related to https://github.com/mikekelly/hal-browser/pull/89 which will provide an explicit token to match, instead of using the closing `</body>` tag.
Spring 4.3's HeaderContentNegotiationStrategy switched from looking up the Accept header via the method returning a single (potentially comma separated) one to the method returning multiple headers in the first place. We now added an override of HttpServletRequestWrapper.getHeaders(…) to out custom adapter defaulting the media type to make sure the defaulting is visible and thus the right handler methods are looked up.
That previously missing caused the DelegatingHandlerMapping selecting the redirect to the HAL browser in case a request to the API root was sent without an accept header as the defaulting of the header to application/hal+json wasn't properly exposed anymore and the redirect to the browser — declaring a produces clause of text/html — was not causing any media type mismatch anymore.
We now use the APIs in place in Spring MVC to make sure we create proper redirects for requests that carry proxy headers so that the redirect target is still going through the proxy.
In case a link relation's target exposes a profile link (via HTTP HEAD and "Link" response header), we now try to obtain a JSON schema from the target resource and use a custom view based on the JSON Editor library fro non-GET requests.
This creates a customized, user friendly pop-up dialog for data entry with a nice polished look. If there is no profile link, we use a fallback editor for raw JSON input.
Original pull request: #191.
RepositoryRestConfiguration now exposes an option to enable enum value serialization and a nested configuration object to tweak the details.
If enabled, a Jackson serializer and deserializer is registered trying to resolve the enum values from the Spring Data REST resource bundle using the fully-qualified enum value name as key. If no explicitly configured value is configured a default translation is triggered that capitalizes the lowercased value name replacing the underscores with spaces (e.g. PAYMENT_EXPECTED -> Payment expected). This can be opted out of, of course.
On the parsing side the deserializer will also consult the resourcebundle and default translation but also accepting the enum name as is (also opt-outable).
Deprecated non-bean-style accessors for projection and metadata configuration on RepositoryRestConfiguration to make these options tweakable via Spring Boot application properties by default.
Added a module that repackages the webjar version of the HAL browser. The repackaging is necessary to be able to control the exposure of the browser dynamically and prevent Spring Boot's auto-exposure of webjars from kicking in.
Tweaked BasePathAwareHandlerMapping to default the Accept header to the one defined in the configuration if none is present in the request or */* is given. This will make sure we default to a JSON dialect in case no header is set.
