1 Answer
1

This listener is since JSF 1.x supposed to be automatically registered by the jsf_core.tld tag library definition file. You can find it in the /META-INF folder of the JSF implementation JAR file. In case of Mojarra 2.1.3 (which you seem to be using according the logs), the listener is registered as follows from line 80 and on:

<!-- ============== Configuration Listener ============== -->
<!--
This ServletContextListener initializes the runtime environment
of the JavaServer Faces Reference Implementation when a web
application including it is initialized by the container.
-->
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>

However, this is apparently not been picked up properly by Jetty. I've also read somewhere that when the FacesServlet is been initialized before the TLD file is been processed, then you will also get exactly this exception. Perhaps this is happening in Jetty. To exclude the one and other, try to remove the <load-on-startup> entry so that it will be loaded only on first concrete HTTP request, far after the TLD is been processed. In any way, explicitly registering the listener in web.xml should indeed solve it.

Further, since JSF 2.x, in addition to the TLD file, the listener is also supposed to be automatically registered by a ServletContainerInitializer implementation in the JAR file in order to workaround a Glassfish 3 bug. In Mojarra 2.x this is the com.sun.faces.config.FacesInitializer class which has the following lines starting at line 131:

// The following line is temporary until we can solve an ordering
// issue in V3. Right now the JSP container looks for a mapping
// of the FacesServlet in the web.xml. If it's not present, then
// it assumes that the application isn't a faces application. In this
// case the JSP container will not register the ConfigureListener
// definition from our TLD nor will it parse cause or JSP TLDs to
// be parsed.
servletContext.addListener(com.sun.faces.config.ConfigureListener.class);

This works in Servlet 3.0 containers only, such as Tomcat 7, Glassfish 3, Jetty 8 (supposedly!), etc. You seem to be using Jetty 8.0 which should thus comply Servlet 3.0, but your web.xml is declared conform Servlet 2.5, so the container will run in Servlet 2.5 fallback modus. Changing your web.xml to conform Servlet 3.0 should trigger this initializer.

I have tried both removing the load-on-startup and switching to 3.0, but still with the same failure. I think it's time to move to tomcat7 again to test things out. I was thinking to use jetty for it's ability to deploy quickly with exploded war with the maven plugin. I'll find other ways for these to work in tomcat7 later. Thank you !
–
bertieOct 26 '11 at 4:26

After enabling the Jetty 8 "annotations" feature, I found that Jetty uses a version of Jasper from GlassFish that intentionally skips the Mojarra ConfigureListener defined in the TLD file. Also, the Mojarra FacesInitializer will not register the Mojarra ConfigureListener if the FacesServlet is defined in web.xml. I got it to work though by registering a custom ServletContainerInitializer. For more details, see Deploying JSF Portlets on Jetty and FACES-1668.
–
Neil GriffinAug 1 '13 at 20:32

@Neil: Nice find! That explains indeed the behavior. Jetty'd better have borrowed Jasper from Tomcat or have developed their own.
–
BalusCAug 1 '13 at 20:36

@BalusC: Thanks for the kind words Bauke. I also found that adding jsf-api.jar and jsf-impl.jar to $JETTY_HOME/lib/jsp is a way of adding Mojarra to the Jetty global classpath that will cause Jetty to auto-register ConfigureListener. Note that the "annotations" feature has to be enabled.
–
Neil GriffinAug 2 '13 at 13:03