actionListener

Use actionListener if you want have a hook before the real business action get
executed, e.g. to log it, and/or to set an additional property
(by <f:setPropertyActionListener>), and/or to have access to the component which
invoked the action (which is available by ActionEvent argument). So, purely for preparing
purposes before the real business action gets invoked.
The actionListener method has by default the following signature:
import javax.faces.event.ActionEvent;
// ...
public void actionListener(ActionEvent event) {
// ...
}
And it's supposed to be declared as follows, without any method parentheses:
<h:commandXxx ... actionListener="#{bean.actionListener}" />
Note that you can't pass additional arguments by EL 2.2. You can however override
the ActionEventargument altogether by passing and specifying custom argument(s). The
following examples are valid:
<h:commandXxx ... actionListener="#{bean.methodWithoutArguments()}" />
<h:commandXxx ... actionListener="#{bean.methodWithOneArgument(arg1)}" />
<h:commandXxx ... actionListener="#{bean.methodWithTwoArguments(arg1,
arg2)}" />
(note the importance of the parentheses in the argumentless method, if they were absent,
JSF would still expect a method with ActionEvent argument)

action
Use action if you want to execute a business action and if necessary handle navigation.
The actionmethod can (thus, not must) return a String which will be used as navigation
case outcome (the target view). A return value of null or void will let it return to the same
page and keep the current view scope alive. A return value of an empty string or the same
view ID will also return to the same page, but recreate the view scope and thus destroy any
currently active view scoped beans and, if applicable, recreate them.
The action method can be any valid MethodExpression, also the ones which uses EL 2.2
arguments, for example:
<h:commandLink value="submit" action="#{bean.edit(item)}" />
With this method:
public void edit(Item item) {
// ...
}
Note that when your action method solely returns a string, then you can also just specify
exactly that string in the action attribute. Thus, this is totally clumsy:
<h:commandLink value="Go to next page" action="#{bean.goToNextpage}" />
With this senseless method returning a hardcoded string:
public String goToNextpage() {
return "nextpage";
}
Instead, just put that hardcoded string directly in the attribute:

<h:commandLink value="Go to next page" action="nextpage" />

Please note that this in turn indicates a bad design: navigating by POST. This is not user
nor SEO friendly. This all is explained in When should I use h:outputLink instead of
h:commandLink? and is supposed to be solved as
<h:link value="Go to next page" outcome="nextpage" />

Invocation order
The actionListeners are always invoked before the action in the same order as they
are been declared in the view and attached to the component. So, the following example
<h:commandLink value="submit" actionListener="#{bean.listener1}"
action="#{bean.submit}">
<f:actionListener type="com.example.SomeActionListener" />
<f:setPropertyActionListener target="#{bean.property}" value="some"
/>
</h:commandLink>
will
invoke Bean#listener1(), SomeActionListener#processAction(), Bean#setPropert
y()and Bean#submit() in this order.

Exception handling
The actionListener supports a special exception: AbortProcessingException. If this
exception is thrown from an actionListener method, then JSF will skip any remaining
action listeners and the action method and proceed to render response directly. You won't
see an error/exception page, JSF will however log it. This will also implicitly be done
whenever any other exception is being thrown from an actionListener. So, if you intend
to block the page by an error page as result of a business exception, then you should
definitely be performing the job in the action method.
If the sole reason to use an actionListener is to have a void method returning to the
same page, then that's a bad one. The action methods can perfectly also return void, on
the contrary to what some IDEs let you believe via EL validation. Note that the PrimeFaces
showcase examples are littered with this kind of actionListeners over all place. This is
indeed wrong. Don't use this as an excuse to also do that yourself.