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
Previously, the ServletContext was configured after any
ServletContextInitializer beans had been initialized. This meant that
any configuration class that provided such a bean would be initialized
before the ServletContext was configured. If the configuration class
used the ServletContext in its initializtaion that it would see it in
its default, unconfigured state.
This commit reworks the configuration of the ServletContext so that
it happens before any ServletContextInitializer beans are initialized.
Closes gh-10699