14

I'm reviewing a current JSF project where the web.xml configuration contains:

  • the FacesServlet (configured on *.xhtml)
  • the 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.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
LaurentG
  • 11,128
  • 9
  • 51
  • 66

1 Answers1

17

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.

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Thank you for the answer. I realized that the `FacesServlet` is actually configured on `/*.xhtml`. I updated the question. – LaurentG Nov 28 '13 at 12:19
  • You're welcome. I'd doublecheck that. This is namely illegal syntax. I updated the Q with right one. – BalusC Nov 28 '13 at 12:19
  • You are right (again). Sorry I checked too fast. I have `*.xhtml`. – LaurentG Nov 28 '13 at 12:40
  • With ICEFaces 3.3.0 and tomcat >= 7.0.42, declaring this listener in web.xml causes a specific icefaces component to be added twice with same id on each page, thus causing an error. See this forum post : http://www.icesoft.org/JForum/posts/list/22121.page – Gaetan Jun 02 '15 at 09:54
  • 1
    I can confirm that the same buggy behavior, where a config listener is created twice, also happens on WebLogic 12.2.1.3. Removing the listener from _web.xml_ resolves it. – Luciano van der Veekens Nov 16 '17 at 10:35