ICEfaces
  1. ICEfaces
  2. ICE-4862

error-page redirection not working in Glassfish v2 when directing to a JSP error page

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Won't Fix
          • Affects Version/s: 1.8.1
          • Fix Version/s: None
          • Component/s: Framework
          • Labels:
            None
          • Environment:
            Glassfish V2
          • Workaround Exists:
            Yes
          • Workaround Description:
            Directing to an HTML page or using Tomcat are some alternatives.

            Description

            When attempting to direct to an error page based in a 404, 500, or other error the default Glassfish error screen is shown instead of the error page. The following error is thrown after the normal error (FacesException/FileNotFoundException):

            ApplicationDispatcher[/dv_lite] PWC1231: Servlet.service() for servlet jsp threw exception
            java.lang.IllegalStateException: PWC3991: getOutputStream() has already been called for this response
                    at org.apache.coyote.tomcat5.CoyoteResponse.getWriter(CoyoteResponse.java:717)
                    at org.apache.coyote.tomcat5.CoyoteResponseFacade.getWriter(CoyoteResponseFacade.java:226)
                    at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:187)
                    at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:180)
                    at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:237)
                    at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:173)
                    at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:124)
                    at org.apache.jsp.error.error_jsp._jspService(error_jsp.java:98)
                    at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:109)
                    at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
                    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:389)
                    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:486)
                    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:380)
                    at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
                    at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:427)
                    at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:875)
                    at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:723)
                    at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:560)
                    at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:490)
                    at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:382)
                    at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:549)
                    at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:339)
                    at org.apache.catalina.core.StandardHostValve.postInvoke(StandardHostValve.java:247)
                    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:649)
                    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
                    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
                    at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096)
                    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166)
                    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
                    at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
                    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
                    at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1096)
                    at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:288)
                    at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:647)
                    at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:579)
                    at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:831)
                    at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
                    at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
                    at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
                    at com.sun.enterprise.web.portunif.PortUnificationPipeline$PUTask.doTask(PortUnificationPipeline.java:380)
                    at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
                    at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)

              Issue Links

              blocks

              Bug - A problem which impairs or prevents the functions of the product. ICE-4303 error-page directive not working with netbeans projects

              • Major - Major loss of function.
              • Closed

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                Arran Mccullough added a comment -

                There is one case where this seems to work, if the browser/user accesses a URL with an Invalid name it will direct to the custom 404 JSP error page.

                Show
                Arran Mccullough added a comment - There is one case where this seems to work, if the browser/user accesses a URL with an Invalid name it will direct to the custom 404 JSP error page.
                Hide
                Permalink
                Deryk Sinotte added a comment - - edited

                I've just started to look at this so I'll make a few notes:

                I can duplicate the issue with the test case. When running the sample app and specifying the URL to be something like:

                [context]/nosuchpage.jsp

                I see the proper error page appear. If I try:

                [context]/nosuchpage.jspx

                I get the container's built in error page rather than the application's. This would be consistent with the fact that JSF + ICEfaces wouldn't handle .jsp pages because the servlets are not mapped to do so. If I do:

                [context]/xmlhttp/blah.jsp

                where the file extension is .jsp but the path (xmlhttp) is mapped to our servlets, I get the same behavior. So it appears that the bottom line is that when the request is mapped to our servlets, the behaviour is incorrect.

                Tomcat appears to work better in that is doesn't show the Tomcat stack trace but it also doesn't show the 500 error when the file is not found (showing the more "general" custom error page for Throwable instead)

                Glassfish 2v2 uses an older version of JSF (mine lists as 1.2_04-b20-p03) than what we'd normally distribute in a Tomcat .war file where we'd include the JSF libraries ourselves. This is likely the difference in behaviour between the two containers.

                Show
                Deryk Sinotte added a comment - - edited I've just started to look at this so I'll make a few notes: I can duplicate the issue with the test case. When running the sample app and specifying the URL to be something like: [context] /nosuchpage.jsp I see the proper error page appear. If I try: [context] /nosuchpage.jspx I get the container's built in error page rather than the application's. This would be consistent with the fact that JSF + ICEfaces wouldn't handle .jsp pages because the servlets are not mapped to do so. If I do: [context] /xmlhttp/blah.jsp where the file extension is .jsp but the path (xmlhttp) is mapped to our servlets, I get the same behavior. So it appears that the bottom line is that when the request is mapped to our servlets, the behaviour is incorrect. Tomcat appears to work better in that is doesn't show the Tomcat stack trace but it also doesn't show the 500 error when the file is not found (showing the more "general" custom error page for Throwable instead) Glassfish 2v2 uses an older version of JSF (mine lists as 1.2_04-b20-p03) than what we'd normally distribute in a Tomcat .war file where we'd include the JSF libraries ourselves. This is likely the difference in behaviour between the two containers.
                Hide
                Permalink
                Ken Fyten added a comment -

                The issue is related to the use of an older JSF runtime version. Updating the runtime version resolves.

                Show
                Ken Fyten added a comment - The issue is related to the use of an older JSF runtime version. Updating the runtime version resolves.

                  People

                  • Assignee:
                    Unassigned
                    Reporter:
                    Arran Mccullough
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    0 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: