Tomcat 7.0.37 JSF app deployment ClassNotFound FacesServlet

Question

Mar 03, 2013 12:09:05 PM org.apache.catalina.core.ApplicationContext log
INFO: Marking servlet Faces Servlet as unavailable
Mar 03, 2013 12:09:05 PM org.apache.catalina.core.StandardContext loadOnStartup
SEVERE: Servlet /mavenproject1 threw load() exception
java.lang.ClassNotFoundException: javax.faces.webapp.FacesServlet
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1713)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1558)
    at org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:527)
    at org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:509)
    at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137)
    at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144)
    at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1088)
    at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5033)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5317)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
    at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
    at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
    at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:657)
    at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1637)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
    at java.util.concurrent.FutureTask.run(FutureTask.java:166)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:722)

When I'm trying to deploy an application with Faces Servlet, I get this stacktrace. This would mean there's no FacesServlet available, but this is clearly not the case since these libraries are available in the WAR.

• jsf-api-2.2.0-m09.jar
• jsf-impl-2.2.0-m09.jar
• javaee-web-api-6.0.jar

I don't have a clue in what might be wrong. As stated in the title, I am running on Tomcat 7.0.37.

Answer 1

The problem is most likely with javaee-web-api-6.0.jar. This jar contains javax.servlet.* classes. And when Tomcat found them in this jar it blocks the jar for classloading. This means that no classes from this jar can be loaded at all! Including javax.faces.webapp.FacesServlet which is in it. See servlet spec (3.0), section 10.7.2:

The class loader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal Java SE semantics using getResource. As described in the Java EE license agreement, servlet containers that are not part of a Java EE product should not allow the application to override Java SE platform classes, such as those in the java.* and javax.* namespaces, that Java SE does not allow to be modified. The container should not allow applications to override or access the container’s implementation classes. It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs. An implementation MUST also guarantee that for every web application deployed in a container, a call to Thread.currentThread.getContextClassLoader() MUST return a ClassLoader instance that implements the contract specified in this section. Furthermore, the ClassLoader instance MUST be a separate instance for each deployed web application. The container is required to set the thread context ClassLoader as described above before making any callbacks (including listener callbacks) into the web application, and set it back to the original ClassLoader, once the callback returns.

Clean up your dependencies!