ActionListener is called multiple times (Bug?) - Mojarra 2.1.3

Question

I have the following button:

   <h:commandButton 
     disabled="#{mybean.searching}"
     binding="#{mybean.searchButton}"
     actionListener="#{mybean.searchForLicenses}"
     value="Search" />

When I debug I see that the actionListener is called twice first, then three times, next click four times and so on.

It seems like on every reload the actionListener is registered one more time.

I'm using Mojarra 2.1.3 (also tried 2.0.6) and Tomcat 7 with IceFaces.

The binding is done that way:

private javax.faces.component.UICommand searchButton;

public void setSearchButton(UICommand searchButton) {
  this.searchButton = searchButton;
}

public UICommand getSearchButton() {
  return searchButton;
}

Answer 1

That can happen if you've bound the component to a session or application scoped bean instead of a request scoped bean. This is simply a bad design. The very same component would be reused among multiple requests/views. You need to put the bean in the request scope, or to get rid of the component binding altogether.

Note that binding the component directly to a bean is often a sign of poor design somewhere in the code. What is it, the functional requirement and/or problem for which you thought that this is the solution? If you elaborate on that, we may be able to propose the right approach.

Also note that using an action listener alone is also a design smell. I'd expect "searchForLicenses" to be a normal action method. See also Differences between action and actionListener.

Answer 2

The similar issue takes place when component is using binding and validator or valueChangListener and backing bean is of View, Session or Application scope. Then corresponding listeners are called many times but not once during request (+1 time with every new request).

One possible solution is to override jsf class AttachedObjectListHolder which is used for storing component listeners. Current implementation simply add new listener to component even though the same listener is already there. So the proposed fix is to check that listener does not exist before adding it.

Details of the fix you can see here