ICEfaces
  1. ICEfaces
  2. ICE-4285

Error handling redirect fails for Glassfish v2 UR2 with JSF 1.2_04

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.8
    • Fix Version/s: 1.8
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      Glassfish v2 ur2, Suin JSF 1.2_04
    • Affects:
      Compatibility/Configuration
    • Workaround Exists:
      Yes
    • Workaround Description:
      Workaround is to update the JSF RI used on Glassfish v2 UR2 to a more recent release, such as JSF 1.2_12.

      Description

      When tested ICE-3007 on glassfish v2 ur2 server, it seems not redirect to the error page

        Activity

        Hide
        Deryk Sinotte added a comment -

        A couple of points to note. The failure appears to occur if either of the following two conditions is met:

        • If concurrentDOMViews=false. Setting it to true appears to work correctly. The test case currently doesn't set this value so it's false by default.
        • If the error page is an ICEfaces page (eg .jspx or .iface depending on the web.xml configuration). A normal .html page seems to work fine regardless of the concurrentDOMView value.
        Show
        Deryk Sinotte added a comment - A couple of points to note. The failure appears to occur if either of the following two conditions is met: If concurrentDOMViews=false. Setting it to true appears to work correctly. The test case currently doesn't set this value so it's false by default. If the error page is an ICEfaces page (eg .jspx or .iface depending on the web.xml configuration). A normal .html page seems to work fine regardless of the concurrentDOMView value.
        Hide
        Deryk Sinotte added a comment -

        At this point, as near as I can figure, the problem may be related to the version of JSF that comes with GlassFish v2 ur2 ().

        What happens during a redirect is that JSF forwards to the new page (e.g. error.iface) and the JSF lifecycle is run for that page. However, it appears that the some errors/events are being "remembered" from the previous page (the one that threw the error intially). Here's a snippet of a stack trace for illustration:

        javax.faces.el.EvaluationException: java.lang.RuntimeException: from action [RuntimeException with message]
        at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:91)
        at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:91)
        at javax.faces.component.UICommand.broadcast(UICommand.java:383)
        at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:447)
        at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752)
        at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
        at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
        at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
        at com.icesoft.faces.webapp.http.core.JsfLifecycleExecutor.apply(JsfLifecycleExecutor.java:16)

        The UICommand.broadcast indicates that the button in the test case that was used to throw the Exception is re-broadcasting. This does not happen with ICEfaces 1.7 but it also doesn't happen with other app servers using newer versions of JSF.

        Show
        Deryk Sinotte added a comment - At this point, as near as I can figure, the problem may be related to the version of JSF that comes with GlassFish v2 ur2 (). What happens during a redirect is that JSF forwards to the new page (e.g. error.iface) and the JSF lifecycle is run for that page. However, it appears that the some errors/events are being "remembered" from the previous page (the one that threw the error intially). Here's a snippet of a stack trace for illustration: javax.faces.el.EvaluationException: java.lang.RuntimeException: from action [RuntimeException with message] at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:91) at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:91) at javax.faces.component.UICommand.broadcast(UICommand.java:383) at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:447) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752) at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97) at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117) at com.icesoft.faces.webapp.http.core.JsfLifecycleExecutor.apply(JsfLifecycleExecutor.java:16) The UICommand.broadcast indicates that the button in the test case that was used to throw the Exception is re-broadcasting. This does not happen with ICEfaces 1.7 but it also doesn't happen with other app servers using newer versions of JSF.
        Hide
        Deryk Sinotte added a comment -

        I tried with Glassfish 2.1, but it only uses a slightly updated version from GF v2 ur2 (1.2_04-b22-p05) and the test case had the same characteristics as noted.

        I also tried against Tomcat 6.0 but with an older version of JSF (1.2_04-b10-p01) but it managed to work fine. So it must be a combination of Glassfish and ICEfaces 1.8 and non-concurrent views that is causing the problem.

        Show
        Deryk Sinotte added a comment - I tried with Glassfish 2.1, but it only uses a slightly updated version from GF v2 ur2 (1.2_04-b22-p05) and the test case had the same characteristics as noted. I also tried against Tomcat 6.0 but with an older version of JSF (1.2_04-b10-p01) but it managed to work fine. So it must be a combination of Glassfish and ICEfaces 1.8 and non-concurrent views that is causing the problem.
        Hide
        Deryk Sinotte added a comment -

        Glassfish v3 appears to work with concurrentDOMViews no matter what it is set to. It uses a much newer version of JSF (1.2_10-b01-FCS).

        Show
        Deryk Sinotte added a comment - Glassfish v3 appears to work with concurrentDOMViews no matter what it is set to. It uses a much newer version of JSF (1.2_10-b01-FCS).
        Hide
        Ken Fyten added a comment -

        Update the JSF runtime to resolve this issue.

        Show
        Ken Fyten added a comment - Update the JSF runtime to resolve this issue.

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Sam Xiao
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: