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

          Activity

          Arran Mccullough created issue -
          Hide
          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.
          Arran Mccullough made changes -
          Field Original Value New Value
          Salesforce Case [5007000000A41Rt]
          Arran Mccullough made changes -
          Attachment Case8572Example.war [ 11938 ]
          Ken Fyten made changes -
          Assignee Ken Fyten [ ken.fyten ]
          Hide
          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.
          Deryk Sinotte made changes -
          Assignee Ken Fyten [ ken.fyten ] Deryk Sinotte [ deryk.sinotte ]
          Ken Fyten made changes -
          Assignee Deryk Sinotte [ deryk.sinotte ] Ken Fyten [ ken.fyten ]
          Ken Fyten made changes -
          Assignee Ken Fyten [ ken.fyten ] Deryk Sinotte [ deryk.sinotte ]
          Ken Fyten made changes -
          Assignee Deryk Sinotte [ deryk.sinotte ] Ken Fyten [ ken.fyten ]
          Ken Fyten made changes -
          Assignee Ken Fyten [ ken.fyten ] Arran Mccullough [ arran.mccullough ]
          Arran Mccullough made changes -
          Assignee Arran Mccullough [ arran.mccullough ] Ken Fyten [ ken.fyten ]
          Hide
          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.
          Ken Fyten made changes -
          Status Open [ 1 ] Closed [ 6 ]
          Resolution Won't Fix [ 2 ]
          Assignee Ken Fyten [ ken.fyten ]
          Ken Fyten made changes -
          Link This issue blocks ICE-4303 [ ICE-4303 ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved: