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.
As `validation-api` 2 is available by default, this commit adds the
integration test as a regular test case. The integration test is kept to
exercise what happens in a standard project.
See gh-11512
The initial solution to gh-11512 was still using a plain `toString` that
could potentially break with a JDK upgrade. Turns out that JDK9 actually
uses the same type for AnnotatedType and ClassType so the trick of using
a visitor doesn't work anymore.
Retrospectively, it is quite easy to generate the full type once we have
the DeclaredType as we already have some logic to get the qualified,
that is raw, type and we have access to the type parameters.
This commit still uses a `toString` to generate the representation of
the type parameters but this looks much safer than trying to redo what
such a simple `toString` should do. Also, the additional metadata that
we could get on an ExecutableElement does not apply to them.
Closes gh-11512
This commit prevents the default error view from rendering itself if the
response has been committed already. In this case, it is impossible to
change the HTTP response status and write a proper response - trying to
do so often results in a `IllegalStateException` since the response body
has already been written to.
Fixes gh-11580
There is a suspicion that the use of epoll is causing the intermittent
failures being tracked by gh-10569. This commit disables the use of
epoll to see if it improves the situation.
See gh-10569
Previously, the default Logback configuration set the console
appenders charset to UTF-8. This was inconsistent with the Logback
file appender and Log4j2's console and file appenders, all of which
used the platform's default.
This commit removes the configuration of the Logback console
appender's charset. This means that it will use the platform's
default charset, aligning it with the Logback file appender and
both Log4j2 appenders.
Closes gh-11611
