This commit makes sure that `CharacterEncodingFilter` is ordered with
the `Ordered.HIGHEST_PRECEDENCE` and that other filters, potentially
reading the request body, are ordered after.
In this particular case, both `WebMvcMetricsFilter` and
`ErrorPageFilter` are now ordered at `Ordered.HIGHEST_PRECEDENCE + 1` to
avoid cases where the request body is read before the encoding
configuration is taken into account.
Closes gh-11607
This commit adds a new `spring-boot-configuration-analyzer` module that
can be added to any app to analyze its environment on startup.
Each configuration key that has a matching replacement is temporarily
transitioned to the new name with a `WARN` report that lists all of
them.
If the project defines configuration keys that don't have a replacement,
an `ERROR` report lists them with more information if it is available.
Closes gh-11301
As explained in the "Split package compatibility" section of
https://blog.jetbrains.com/kotlin/2017/09/kotlin-1-2-beta-is-out/
kotlin-stdlib-jdk7 and kotlin-stdlib-jdk8 are the recommended
dependencies to use with Kotlin 1.2 for Java 9+ compatibility.
Closes gh-11716
Add `@ControllerEndpoint` and `@RestControllerEndpoint` annotations that
can be used to develop a Spring-only request mapped endpoint. Both
Spring MVC and Spring WebFlux are supported.
This feature is primarily for use when deeper Spring integration is
required or when existing Spring Boot 1.5 projects want to migrate to
Spring Boot 2.0 without re-writing existing endpoints. It comes at the
expense of portability, since such endpoints will be missing from
Jersey.
Fixes gh-10257
Create a `PathMappedEndpoint` interface that allows any `ExposedEndpoint`
to provide root path details. The `EndpointPathResolver` interface has
been renamed to `PathMapper` and is now only used during endpoint
discovery.
`EndpointPathProvider` has been replaced with `PathMappedEndpoints`
which simply finds relevant path mapped endpoints.
Fixes gh-10985
Refactor several areas of the actuator endpoint code in order to make
future extensions easier. The primary goal is to introduce the concept
of an `ExposableEndpoint` that has technology specific subclasses and
can carry additional data for filters to use. Many other changes have
been made along the way including:
* A new EndpointSupplier interface that allows cleaner separation of
supplying vs discovering endpoints. This allows cleaner class names
and allows for better auto-configuration since a user can choose to
provide their own supplier entirely.
* A `DiscoveredEndpoint` interface that allows the `EndpointFilter`
to be greatly simplified. A filter now doesn't need to know about
discovery concerns unless absolutely necessary.
* Improved naming and package structure. Many technology specific
concerns are now grouped in a better way. Related concerns are
co-located and concepts from one area no longer leakage into another.
* Simplified `HandlerMapping` implementations. Many common concerns have
been pulled up helping to create simpler subclasses.
* Simplified JMX adapters. Many of the intermediary `Info` classes have
been removed. The `DiscoveredJmxOperation` is now responsible for
mapping methods to operations.
* A specific @`HealthEndpointCloudFoundryExtension` for Cloud Foundry.
The extension logic used to create a "full" health endpoint extension
has been made explicit.
Fixes gh-11428
Fixes gh-11581
Previously, the server was created with out an explicitly configured
address. This lead to it using any local address which will prefer
IPv6 (::0) if it's available. By contrast, the client was created
with a base URL that specified localhost as the host. This meant the
the client would prefer to connect to IPv4. Normally this wouldn't
cause a problem as nothing would be listening on the port in the IPv4
stack so the client would then connect to the server being tested
using the IPv6 stack. However, if another process was listening to the
port in the IPv4 stack, the client would connect to the wrong server.
This could lead to an unexpected 404 response (if the wrong server
was an HTTP server) or a hang if it was not.
There's a chance, although I think it's unlikely, that the problem
described above is the cause of gh-10569. I think it's unlikely as
the hang tracked by gh-10569 only occurs when running the WebFlux
endpoint integration tests using Reactor Netty. If it was the problem
described above, there's no reason that I can think of why we
wouldn't have also seen it with the Web MVC endpoint integration
tests.
Andy Wilkinson
Brian Clozel
Stephane Nicoll
sdeleuze
Johnny Lim
Phillip Webb
Madhura Bhave
igor-suhorukov