I can't see anything in the servlet spec that indicates that the
behaviour of Undertow is incorrect.
Can you file a JIRA in the Undertow JIRA, and also in the Servlet Spec
JIRA asking for a clarification in the spec?
If this is how all other containers handle the sendRedirect then I will
change Undertow to match, however it would be better if this was
explicitly specified in the spec.
Stuart
arjan tijms wrote:
Hi,
Contrary to other servers (Tomcat, JBoss AS 7/EAP 6, GlassFish and
probably all others), Undertow immediately performs a forward when
HttpServletResponse#sendError() is invoked instead of waiting until
all servlets and filters of the application are finished.
In case the error page happens to be a Facelets page, this forward
causes the FacesServlet to be invoked once again, basically creating
another FacesContext inside the same thread. This overrides the
previous FacesContext. After that is released, the "original"
FacesContext is never put back.
In OmniFaces we created a workaround for this, see
https://github.com/omnifaces/omnifaces/commit/b9badb86cb2112fd87485e060db...
Unfortunately, this OmniFaces workaround isn't bulletproof. In case of
an HTTP 400, PrimeFaces loses its RequestContext as well and OmniFaces
can't help setting it back.
This results in exceptions like the following:
java.lang.NullPointerException
at
org.primefaces.context.PrimeFacesContext.release(PrimeFacesContext.java:26)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:665)
Although not confirmed, this behaviour from Undertow is the likely
cause of a large number of other exceptions as well.
Kind regards,
Arjan Tijms
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev