javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-2148

Swallowing exception, although explicitly forbidden by the JSF specification, takes place in UIViewRoot.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Incomplete
    • Affects Version/s: 2.0.2, 2.0.4, 2.1.0, 2.1.1, 2.1.2
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Mojarra 2.x

      Description

      In the issue #2059 I reported that some desirable functionality would be implemented for more comfortable work. Then, I read in the JSF 2.1 specification that not only this is desirable, but even required. So, I decided to report it again - this time as a bug.

      Section 6.2 "Exception Handler" clearly states that all exceptions but ValidationException, ConverterException, MissingResourceException from <f:loadBundle /> and exceptions from @PreDestroy must not be swalled. However, encodeBegin() and encodeEnd() methods of javax.faces.component.UIViewRoot swallow every exception. Furthermore, this behavior is intended according to comments upon those methods:

      /**
      *(...) Any errors

      • that occur during invocation of any of the the beforePhase
      • listeners must be logged and swallowed.(...)
        */

      This contradicts to what the specification says.

      Since during the render phase <phaseListener />'s are called only then, and not in the doPhase() method (inherited by com.sun.faces.lifecycle.RenderResponsePhase from com.sun.faces.lifecycle.Phase), any exception coming from beforePhase or afterPhase (implementation of javax.faces.event.PhaseListener interface) is swallowed and not passed to the exception handler.

      Regards,

      P.S. I am afraid I cannot delete the issue #2059.

        Issue Links

          Activity

          Hide
          Manfred Riem added a comment -

          Can you attach an example application (with sources) that demonstrates the problem? Can you verify if this still an issue on the latest 2.1 release?

          Show
          Manfred Riem added a comment - Can you attach an example application (with sources) that demonstrates the problem? Can you verify if this still an issue on the latest 2.1 release?
          Hide
          klhoste added a comment -

          Hi, I'm facing a similar issue with the latest release (2.1.14), but with a PhaseListener declared as managed bean, used in <f:phaseListener binding="#

          {externalAccessListener}

          " /> in a page, and listening before RESTORE_VIEW phase.
          My phaseListener checks some URL parameters and forwards to another page if the check is OK, or throws an exception that is managed by an ExceptionHandler. Unfortunately the exception is not enqueued, the origin of the issue is the same as #2059.

          Do you think there could be a workaroud ?

          Show
          klhoste added a comment - Hi, I'm facing a similar issue with the latest release (2.1.14), but with a PhaseListener declared as managed bean, used in <f:phaseListener binding="# {externalAccessListener} " /> in a page, and listening before RESTORE_VIEW phase. My phaseListener checks some URL parameters and forwards to another page if the check is OK, or throws an exception that is managed by an ExceptionHandler. Unfortunately the exception is not enqueued, the origin of the issue is the same as #2059. Do you think there could be a workaroud ?
          Hide
          Manfred Riem added a comment -

          Just to verify, are you saying the same problem exists in 2.1.14?

          Show
          Manfred Riem added a comment - Just to verify, are you saying the same problem exists in 2.1.14?
          Hide
          Manfred Riem added a comment -

          Lowering priority because of no response

          Show
          Manfred Riem added a comment - Lowering priority because of no response
          Hide
          Manfred Riem added a comment -

          Lowering priority because of no response

          Show
          Manfred Riem added a comment - Lowering priority because of no response
          Hide
          Manfred Riem added a comment -

          Closing out because of inactivity

          Show
          Manfred Riem added a comment - Closing out because of inactivity

            People

            • Assignee:
              Unassigned
              Reporter:
              pablo53
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: