Previously, the error page filter used sendError to set the response
status when handling an exception and before forwarding the request
to the error controller. Following the fix for gh-11814, this meant
that the error controller was unable to write its response and the
containers default error page was returned instead.
This commit updates the error page filter to use setStatus rather than
sendError. This ensures that the response has the correct status code
while allowing the error controller to write its body. Tests have
been added to the Tomcat deployment test suite to verify that the
error page filter behaves as intended when dealing with a sent error
and an exception for requests accepting HTML, JSON, or anything.
Closes gh-12787
In Logback 1.1.10, the logback-classic module contains a
META-INF/services/javax.servlet.ServletContainerInitializer file that
contains a comment. This triggers a bug in Wildfly 8 [1] that has been
fixed [2] in Wildfly 9 and later. As a result, this commit also
updates our Wildfly deployment test to use 9.0.2 rather than 8.2.0.
Closes gh-8354
[1] https://issues.jboss.org/browse/WFLY-4089
[2] fef57ebdc7
The changes made in a6c1668b mean that the web starter no longer
depends on spring-boot-starter-validation. Instead, it depends
directly on hibernate-validator. This means that the exclusion of the
validation starter in the TomEE deployment test app no longer matches
anything and hibernate-validator is packaged in the war. This breaks
the application as TomEE ships with Bean Validation 2.0 and the
version of Hibernate Validator being used requires 2.1.
This commit updates the exclusions in the TomEE deployment app so that
hibernate-validator is excluded once again. This allows the app to
use TomEE's bundled Bean Validation implementation.
The stale spring-boot-starter-validation exclusion has been removed
from the Wildfly deployment test app. It is redundant as Wildfly ships
with Bean Validation 2.1. This brings this test app into line with
the Glassfish test app.
Closes gh-5454
For some reason, Cargo fails when the Tomcat deployment tests are run
after the TomEE deployment tests. It complains that it can’t find one
of its own classes. This commit changes the order so that the TomEE
tests run before the Tomcat tests.
\_(ツ)_/¯
FacesListener in Mojarra 2.2.12 (used in Glassfish 4.1.1) is a
ServletContainerInitializer that’s annotated to handle types annotated
with javax.annotation.Resource.
OAuth2RestOperationsConfiguration.SessionScopedConfiguration is one such
class. This leads to com.sun.faces.config.DelegatingAnnotationProvider
calling getAnnotations on SessionScopedConfiguration.class. This fails
with a java.lang.ArrayStoreException due to SessionScopedConfiguration
being annotated with @ConditionalOnBean(OAuth2ClientConfiguration) and
OAuth2ClientConfiguration not being on the classpath.
DelegatingAnnotationProvider currently catches NoClassDefFoundErrors
thrown during its annotation processing. It needs to be made more
robust so that it also copes with an ArrayStoreException, in a similar
way to how org.glassfish.apf.impl.AnnotationProcessorImpl was updated to
fix GLASSFISH-21265 [1]. I’ve opened an issue to this effect [2].
In the meantime, we can work around the brittleness in
DelegatingAnnotationProvider by restructuring
SessionScopedConfiguration. This commit moves the use of @Resource into
a nested inner class, ClientContextConfiguration, while leaving the use
of @ConditionalOnBean on SessionScopedConfiguration. This means that it
is now ClientContextConfiguration that is passed to FacesListener and
processed by DelegatingAnnotationProcessor, thereby avoiding exposing
it to the @ConditionalOnBean annotation that it does not handle
gracefully. A Glassfish-based deployment test has also been added to
verify the fix.
Closes gh-2079
Closes gh-4321
[1] https://java.net/jira/browse/GLASSFISH-21265
[2] https://java.net/jira/browse/JAVASERVERFACES-4076
