2
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.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
Menno
  • 12,175
  • 14
  • 56
  • 88
  • 3
    Exceptions don't lie. Those libraries are definitely absent in `/WEB-INF/lib` of the WAR. I see that you're using Maven. Extract and explore the Maven-produced WAR and you'll see. Reframe the question accordingly; it's not a JSF problem, but a Maven problem. – BalusC Mar 03 '13 at 11:59
  • The list of JARs is the one from inside the WAR (`PROJECT/target/PROJECT.war/WEB-INF/lib/`), as stated in the question. That's the exact reason for posting this, you're right though that exceptions don't lie. – Menno Mar 03 '13 at 12:32
  • I have tried this using another project, but Tomcat still throws the error from above (from the first project). Even though this application is no longer deployed? – Menno Mar 03 '13 at 14:23
  • You've not cleaned up your tomcat installation, that's why you get an exception from first project. – madhead Mar 03 '13 at 15:19

1 Answers1

3

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!

madhead
  • 31,729
  • 16
  • 153
  • 201
  • This would mean I cannot make use of any classes in `javax.servlet` at all? – Menno Mar 03 '13 at 15:48
  • No. This means that you should not pack them in your war. They are **provided** to you by servlet container. Check [maven's provided scope](http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope). – madhead Mar 03 '13 at 15:49
  • Ah, like so. Thank you! Will clean up my dependencies. In another comment you mentioned cleaning up the tomcat installation, how should I get rid of old deployments? Removing the folder from the `/work` directory (I am new with Tomcat)? – Menno Mar 03 '13 at 16:01
  • Generally, it means that your old war is in server's context lookup path. It includes `webapps` folder for Tomcat itself. But Eclipse, for example, deploys applications to `wtpwebapps`... So check for war file presence. – madhead Mar 03 '13 at 16:04
  • Very helpful. I face the same situation with Apache Tomcat 9.0.3 , lib javaee-api 6. – Vy Do Feb 13 '20 at 04:38