I'm reviewing a current JSF project where the web.xml
configuration contains:
*.xhtml
)com.sun.faces.config.ConfigureListener
I'm using JSF 2.2 and Mojarra implementation.
I'm confused about the ConfigureListener
. Is this class needed in the configuration? What is the goal of this class? I couldn't find any information and the class has almost no javadoc.
If I remove this configuration, everything seem to work the same way. Thus I guess that the ConfigureListener
could or should be removed but I am not sure.
The ConfigureListener
is normally automatically registered via /META-INF/jsf_core.tld
file of Mojarra implementation JAR file. Additionally, the ConfigureListener
is explicitly registered via a Servlet 3.0 ServletContainerInitializer
in order to workaround an old GlassFish v3 bug (note: v3, not 3.0.x, thus really that one first GF3 version ever).
There exist situations wherein the auto-registration via .tld
file is insufficient. The well known one is when the webapp is deployed to Jetty. This is explained in detail in this Q&A: could not find Factory: javax.faces.context.FacesContextFactory.
Also, as mentioned before and in that detailed answer, GlassFish v3 has a bug wherein the TLD file is scanned too late and thus JSF couldn't do its necessary initialization thing at the right moment. You'd then need to explicitly register the ConfigureListener
in webapp's web.xml
.
But if it works for you when it's not explicitly registered in web.xml
, then just keep it out. Less noise in web.xml
is better. But if you happen to possibly deploy to a container sensitive to the mentioned problem (so when your webapp is actually a publicly distributed one and you have no control over choice of target container), then you'd better keep it in "for the case that".
Update: It appears that Tomcat 8.x shows buggy behavior when this entry is enabled in web.xml
: this listener will actually be executed twice instead of only once. The consequence is disastrous: among others, all JSF event listeners will be registered twice and component libraries will be loaded twice. This leads only to conflicts during runtime. In other words, when deploying to Tomcat, make sure that this entry is removed from web.xml
.