Pages being processed are merely left blank half way through on errors/exceptions instead of forwarding to the error page specified in web.xml
Asked Answered
C

1

7

In web.xml, I have the following configurations for a global error page.

<error-page>
    <error-code>401</error-code>
    <location>/WEB-INF/error_pages/GeneralError.xhtml</location>
</error-page>

<error-page>
    <error-code>403</error-code>
    <location>/WEB-INF/error_pages/GeneralError.xhtml</location>
</error-page>

<error-page>
    <error-code>404</error-code>
    <location>/WEB-INF/error_pages/GeneralError.xhtml</location>
</error-page>

<error-page>
    <error-code>500</error-code>
    <location>/WEB-INF/error_pages/GeneralError.xhtml</location>
</error-page>

<error-page>
    <error-code>503</error-code>
    <location>/WEB-INF/error_pages/GeneralError.xhtml</location>
</error-page>

When any exception occurs (that result in 500 internal server error), the request is expected to be dispatched to the error page specified but when an exception occurs, the page which is being processed is just left blank in half way through. It does not forward to the error page.

Configuring java.lang.Throwable or java.lang.Exception as follows,

<error-page>
    <exception-type>java.lang.Throwable</exception-type>
    <location>/WEB-INF/error_pages/GeneralError.xhtml</location>
</error-page>

also did not help anymore.


The full contents of web.xml :

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.1" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd">
    <context-param>
        <param-name>javax.faces.FACELETS_LIBRARIES</param-name>
        <param-value>/WEB-INF/my.taglib.xml</param-value>
    </context-param>

    <context-param>
        <param-name>javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE</param-name>
        <param-value>true</param-value>
    </context-param>
    <context-param>
        <param-name>javax.faces.PROJECT_STAGE</param-name>
        <param-value>Production</param-value>
    </context-param>

    <context-param>
        <param-name>com.sun.faces.enableViewStateIdRendering</param-name>
        <param-value>true</param-value>
    </context-param>
    <context-param>
        <param-name>com.sun.faces.enableRestoreView11Compatibility</param-name>
        <param-value>true</param-value>
    </context-param>

    <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>server</param-value>
    </context-param>

    <context-param>
        <param-name>log4jConfigLocation</param-name>
        <param-value>/WEB-INF/log4j.properties</param-value>
    </context-param>

    <context-param>
        <param-name>log4jExposeWebAppRoot</param-name>
        <param-value>false</param-value>
    </context-param>

    <filter>
        <filter-name>PrimeFaces FileUpload Filter</filter-name>
        <filter-class>org.primefaces.webapp.filter.FileUploadFilter</filter-class>
    </filter>

    <filter-mapping>
        <filter-name>PrimeFaces FileUpload Filter</filter-name>
        <servlet-name>Faces Servlet</servlet-name>
    </filter-mapping>

    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.xhtml</url-pattern>
    </servlet-mapping>


    <error-page>
        <error-code>401</error-code>
        <location>/WEB-INF/error_pages/GeneralError.xhtml</location>
    </error-page>

    <error-page>
        <error-code>403</error-code>
        <location>/WEB-INF/error_pages/GeneralError.xhtml</location>
    </error-page>

    <error-page>
        <error-code>404</error-code>
        <location>/WEB-INF/error_pages/GeneralError.xhtml</location>
    </error-page>

    <error-page>
        <error-code>500</error-code>
        <location>/WEB-INF/error_pages/GeneralError.xhtml</location>
    </error-page>

    <error-page>
        <error-code>503</error-code>
        <location>/WEB-INF/error_pages/GeneralError.xhtml</location>
    </error-page>

    <error-page>
        <exception-type>java.lang.Throwable</exception-type>
        <location>/WEB-INF/error_pages/GeneralError.xhtml</location>
    </error-page>

    <security-constraint>
        <display-name>AdminConstraint</display-name>
        <web-resource-collection>
            <web-resource-name>ROLE_ADMIN</web-resource-name>
            <description/>
            <url-pattern>/admin_side/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <description/>
            <role-name>ROLE_ADMIN</role-name>
        </auth-constraint>
        <user-data-constraint>
            <description/>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>

    <security-constraint>
        <display-name>UserConstraint</display-name>
        <web-resource-collection>
            <web-resource-name>ROLE_USER</web-resource-name>
            <description/>
            <url-pattern>/user_side/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <description/>
            <role-name>ROLE_USER</role-name>
        </auth-constraint>
        <user-data-constraint>
            <description/>
            <transport-guarantee>CONFIDENTIAL</transport-guarantee>
        </user-data-constraint>
    </security-constraint>


    <login-config>
        <auth-method>FORM</auth-method>
        <realm-name>projectRealm</realm-name>
        <form-login-config>
            <form-login-page>/utility/Login.xhtml</form-login-page>
            <form-error-page>/utility/ErrorPage.xhtml</form-error-page>
        </form-login-config>
    </login-config>
    <security-role>
        <description/>
        <role-name>ROLE_ADMIN</role-name>
    </security-role>
    <security-role>
        <description/>
        <role-name>ROLE_USER</role-name>
    </security-role>
    <!--error-page>
        <exception-type>javax.faces.application.ViewExpiredException</exception-type>
        <location>/utility/Login.xhtml</location>
    </error-page-->

    <session-config>
        <session-timeout>
            120
        </session-timeout>
        <tracking-mode>COOKIE</tracking-mode>
    </session-config>
    <welcome-file-list>
        <welcome-file>utility/Login.xhtml</welcome-file>
    </welcome-file-list>
</web-app>

Also tried on a blank project with only a single XHTML page and nothing other than error page configurations in web.xml. Pages are merely left blank half way through instead of forwarding to the error page, when an exception occurs (among other HTTP status, only 404 works).

How to dispatch to a specified error page, when any exception/error occurs?


Update 1 :

According to this question/answer, I added the context parameter javax.faces.FACELETS_BUFFER_SIZE to web.xml to have 64KB buffer size but nothing new happened. It still does not forward to the error page, if an exception occurs. Pages are just partially processed and left blank in half way through, if an exception/error occurs. The exception stacktrace is only found on the server terminal and not on the web page (in case 500 internal server error). I deliberately make the application throw an exception to see, if it forwards to the error page.


Update 2 :

After setting the buffer size as mentioned in edit 1, I got the following exception at a certain time (when a request is redirected to a secured area after a successful login). So, I removed that parameter for now.

Severe:   Error Rendering View[/utility/Login.xhtml]
java.lang.IllegalStateException
    at org.apache.catalina.connector.ResponseFacade.setBufferSize(ResponseFacade.java:285)
    at com.sun.faces.context.ExternalContextImpl.setResponseBufferSize(ExternalContextImpl.java:923)
    at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1162)
    at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:403)
    at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133)
    at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
    at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
    at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
    at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
    at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
    at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:72)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
    at filter.LoginNocacheFilter.doFilter(LoginNocacheFilter.java:39)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
    at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
    at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
    at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
    at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
    at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
    at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
    at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
    at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
    at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
    at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
    at java.lang.Thread.run(Thread.java:745)

Info:   Exception when handling error trying to reset the response.
java.lang.IllegalStateException
    at org.apache.catalina.connector.ResponseFacade.setBufferSize(ResponseFacade.java:285)
    at com.sun.faces.context.ExternalContextImpl.setResponseBufferSize(ExternalContextImpl.java:923)
    at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1162)
    at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:403)
    at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:133)
    at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
    at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337)
    at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
    at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
    at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1682)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:344)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
    at org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:72)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
    at filter.LoginNocacheFilter.doFilter(LoginNocacheFilter.java:39)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:316)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:734)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:673)
    at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:174)
    at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:415)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:282)
    at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
    at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
    at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:201)
    at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:175)
    at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
    at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
    at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
    at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
    at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
    at java.lang.Thread.run(Thread.java:745)

Update 3 :

I tried to increase the buffer size (100002400 that's too much) until the error java.lang.OutOfMemoryError: Java heap space is issued. Therefore, the output buffer size should not be the problem.

In Ajaxical things, error pages by the way, are correctly rendered on errors during asynchronous requests by means of OmniFaces - org.omnifaces.exceptionhandler.FullAjaxExceptionHandlerFactory configured in faces-config.xml.

Perhaps, it could have been possible to see the cause of the problem, if I had configured error pages in the beginning - when I started the application and the application consequently had no much extra overhead that it currently has with many XHTML pages, CDI managed beans, EJB session beans etc but anyway I overwhelmed it.


Update 4:

I am now running the same application on WildFly 9.0.2 final. The problem remains unchanged.

Cirilla answered 4/11, 2014 at 17:50 Comment(10)
Have you tried this in a completely different container? Maybe JBoss?Torsi
It is GlassFish Server 4.1 only and it is the only application which was deployed to the server. Other servers were closed while GlassFish was running. @TorsiCirilla
My point here is that you should try to eliminate the possibility of a bug in your container; Try to deploy the the same app to a different containerTorsi
Superficially WildFly does not properly interact/communicate with NetBeans IDE nor I am accustomed to using Eclipse or other IDEs like intelliJ. Therefore, I find it hard to deploy the application to a different server for now. @TorsiCirilla
As you're using OmniFaces anyway, consider using GzipResponseFilter. Like the FullAjaxExceptionHandler, it forcibly buffers everything until javax.faces.FACELETS_BUFFER_SIZE. It isn't a solution, but it should work around this problem.Serna
@Serna : I tried using GzipResponseFilter. It throws java.lang.IllegalStateException: Current state = FLUSHED, new state = CODING_END, when a user is redirected after successful login. Someone already asked the question.Cirilla
I never managed to reproduce that exception. Perhaps you've another filter in your webapp which also does something special with the response? Apart from that exception, did using the GzipResponseFilter solve the in the question mentioned issue?Serna
I am using JAAS. There is a Filter which is very similar to the one as mentioned in this question (I made a few changes afterwards). There seems to be nothing special in that filter. This Filter is mapped to a URL pattern /WEB-INF/jaas/* (it was changed after that question). There is only one page temp.jsp in /WEB-INF/jaas/. The request is dispatched to this page, when a user clicks the login submit button (the code to dispatch is written in an action method in a managed bean). The user is treated accordingly based on the credentials given.Cirilla
As to the concrete problem - when that exception occurs java.lang.IllegalStateException: Current state = FLUSHED, new state = CODING_END (it occurs, when a user is redirected after successful login [to a secure (admin side) / public (user side) home page]), it goes to an error page only once (for that exception only) but then onwards, if further exceptions occur in the application later on, the processing of that page is left half way through as usual. Perhaps, it requires more digging/debugging in the application. I will keep on trying even after the bounty expires.Cirilla
@Torsi : The application suffers from the same problem on WildFly 9.0.2 final.Cirilla
P
-1

Check by increasing the size of your error page GeneralError.xhtml. Sometimes the server doesn't display the error page if it is smaller in size. i.e. try adding some more 50-100 lines of text to GeneralError.xhtml and check)

Pillsbury answered 8/6, 2015 at 4:14 Comment(3)
This is not server specific. This is browser specific. Particularly the one developed by a team somewhere in Redmond. There are better ways to display the error page anyway. Moreover, this is not the cause of OP's concrete problem as the browser in question doesn't display a entirely blank page instead.Serna
When sever doesnt display the correct page, the browser will choose to display the default error page which it has.Pillsbury
As said, this is not the problem here. Read the question once again. If you actually don't understand anything from it, why are you answering it?Serna

© 2022 - 2024 — McMap. All rights reserved.