Action listener activation in many phases

Question

I need action listener (methods) to be activated in many phases. I.e., when the user clicks a submit button, I want code to be executed (in my case) after the validation phase and after (during) the invoke application phase. In earlier version of the standard, I would just register 2 listeners, returning the appropriate getPhaseId() value. Since this method is removed from the current standard, things get more complicated.
QUESTION: Why in heavens name was this method removed from the standard? I suppose, because it is difficult to support with listener methods (in contrast to instances)? Bit of a rough solution, no? Or am I missing something?
I have a solution now, I think, that is based on getting the action event immediate, and requeuing the event again and again.
In the JSP, in the JSF form, I have a submit button as follows:
<h:commandButton id="buttonId" value="ButtonText"
                 actionListener="#{handler.buttonListener}"
                 immediate="true"/>The method Handler.buttonListener is:
  public final void buttonListener(ActionEvent ae) {
    LOG.debug("Handler. buttonListener called ("
              + "ActionEvent.getPhaseId() = " + ae.getPhaseId()
              + "; ActionEvent.getComponent() = " + ae.getComponent()
              + ")");
    PhaseId phaseId = ae.getPhaseId();
    if (phaseId.equals(PhaseId.APPLY_REQUEST_VALUES)) {
      LOG.debug("-- processing during " + ae.getPhaseId());
      // meaningful stuff here
      // prepare for execution in next phase
      ae.queue();
        /* this sets phase id to the current phase, so it is extremely important that
         * we set the necessary phase id AFTER queuing the event */
      ae.setPhaseId(PhaseId.PROCESS_VALIDATIONS);
      LOG.debug("-- ActionEvent (getPhaseId() = " + ae.getPhaseId() + ") queued");     
    else if (phaseId.equals(PhaseId.PROCESS_VALIDATIONS)) {
      LOG.debug("-- processing during " + ae.getPhaseId());
      // meaningful stuff here
      // prepare for execution in next phase
      ae.queue();
      /* this sets phase id to the current phase, so it is extremely important that
       * we set the necessary phase id AFTER queuing the event */
      ae.setPhaseId(PhaseId.INVOKE_APPLICATION);
      LOG.debug("-- ActionEvent (getPhaseId() = " + ae.getPhaseId() + ") queued");     
    else if (phaseId.equals(PhaseId.INVOKE_APPLICATION)) {
      LOG.debug("-- processing during " + ae.getPhaseId());
      // meaningful stuff here
    LOG.debug("Handler. buttonListener done");
  }The /* */ comment in the code is there because the queue methods (on the event as well as the component) set the phase id of the event to the current phase. If I set the phase id of the event before queuing it, that setting is undone, and I get an infinite loop! This is weird, and my solution is at least shaky: it doesn't feel stable across JSF implementations and future releases. I could not find a queue method that leaves the phase id alone.
QUESTION: am I missing something?
The output however is:
Mar 21, 2005 12:51:11 PM org.exadel.jsf.PhaseTracker beforePhase
INFO: BEFORE RESTORE_VIEW 1
Mar 21, 2005 12:51:11 PM org.exadel.jsf.PhaseTracker afterPhase
INFO: AFTER RESTORE_VIEW 1
Mar 21, 2005 12:51:11 PM org.exadel.jsf.PhaseTracker beforePhase
INFO: BEFORE APPLY_REQUEST_VALUES 2
12:51:12,119 DEBUG Handler:550 - Handler.buttonListener called
      (ActionEvent.getPhaseId() = APPLY_REQUEST_VALUES 2;
       ActionEvent.getComponent() = javax.faces.component.html.HtmlCommandButton@33b99a)
12:51:12,171 DEBUG Handler:556 - -- processing during APPLY_REQUEST_VALUES 2
12:51:12,184 DEBUG Handler:564 - -- ActionEvent (getPhaseId() = PROCESS_VALIDATIONS 3) queued
12:51:12,189 DEBUG Handler:580 - Handler.buttonListener done
12:51:12,220 DEBUG Handler:550 - Handler.buttonListener called
     (ActionEvent.getPhaseId() = PROCESS_VALIDATIONS 3;
      ActionEvent.getComponent() = javax.faces.component.html.HtmlCommandButton@33b99a)
12:51:12,255 DEBUG Handler:567 - -- processing during PROCESS_VALIDATIONS 3
12:51:12,256 DEBUG Handler:574 - -- ActionEvent (getPhaseId() = INVOKE_APPLICATION 5) queued
12:51:12,257 DEBUG Handler:580 - Handler.buttonListener done
12:51:12,265 DEBUG Handler:550 - Handler.buttonListener called
    (ActionEvent.getPhaseId() = INVOKE_APPLICATION 5;
     ActionEvent.getComponent() = javax.faces.component.html.HtmlCommandButton@33b99a)
12:51:12,267 DEBUG Handler:577 - -- processing during INVOKE_APPLICATION 5
12:51:12,268 DEBUG Handler:580 - Handler.buttonListener done
Mar 21, 2005 12:51:12 PM org.exadel.jsf.PhaseTracker afterPhase
INFO: AFTER APPLY_REQUEST_VALUES 2
Mar 21, 2005 12:51:12 PM org.exadel.jsf.PhaseTracker beforePhase
INFO: BEFORE RENDER_RESPONSE 6
Mar 21, 2005 12:51:12 PM org.exadel.jsf.PhaseTracker afterPhase
INFO: AFTER RENDER_RESPONSE 6The info is generated by a phase listener I found somewhere (sorry for the lack of reference here to the author). As you can see, I get 3 consecutive calls of my listener method, but they are all during the apply request values phase, and we jump from the apply request values phase immediately to the render response phase, skipping all the other phases, although my listener is actually called 3 times.
QUESTION: what the fuck? What is happening here, and more important, how can I fix it?

Answer 1

I am in touch with IBM about any patch they might have for this. I just thought I'd post details from what I researched.
Basically I found that if I had CommandButton and/or CommandLink components on my page and clicked them for a total greater than 15 times, the application just quit reacting to any of the clicks. After writing a PhaseListener I discovered that after 15 clicks the JSF lifecycle was going straight from the Restore View (1) to Render Response (6) phase instead of going through the ones in between.
I downloaded the JSF source code and tracked down the magic number 15. As mentioned earlier in this forum it has to do with the number of views per session. In the Sun JSF-RI com.sun.faces.application.StateManagerImpl class
the number of views is defaulted to 15. When the number of views hits the max the oldest view is deleted. Somehow I don't think they are deleting the oldest view or else why my app quits after 15 clicks I do not know. Anyway this is a known issue with the Sun JSF-RI and documented in their Release Notes.
Depending on the JSF implementation there may or may not be a workaround. I mean to say the the workaround is not part of the JSF spec but Sun's implementation has a feature where you can configure the com.sun.faces.NUMBER_OF_VIEWS_IN_SESSION value in the web.xml file under the <context-param> tag. If you set the value sufficiently high you lower the risk of the app quitting on you (like a user may be unlikely to make 100 or even 50 clicks on the same page). You might also want to set the state to be saved on the server by setting javax.faces.STATE_SAVING_METHOD to server in another <context-param> tag. Somehow setting this state to client caused errors (NullPointerException) in our app in one of the Faces classes itself.
Hope this helps someone out there.