CODEWITHSUNDEEP
javatomcatjava-ee-5
mkoryak
mkoryak

Reputation: 57988

java.lang.NoClassDefFoundError: HttpSessionListener

I am trying to deploy a war that i didnt write and i am getting this error in my logs:

java.lang.NoClassDefFoundError: HttpSessionListener

i know that HttpSessionListener lives in servlet-api.jar which is found in the lib dir of tomcat(my app server).

I tried including servlet-api.jar in the war's WEB-INF/lib folder, but the logs yelled at me for doing that:

INFO: validateJarFile(/home/test/apache-tomcat-6.0.18/webapps/test/WEB-INF/lib/servlet-api.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class

the internets claim that you dont have to include that class in your lib folder.

edit: i removed the offending listener (which was causing the problem above) from web.xml because it didnt look very important. this revealed more errors:

java.lang.Error: Unresolved compilation problem: 
    The type javax.servlet.FilterChain cannot be resolved. It is indirectly referenced from required .class files

what am i missing?

Upvotes: 3

Views: 20148

Answers (4)

Nick Legend
Nick Legend

Reputation: 1058

Though the question is too old will tell about a possible problem nowadays. As per the Tomcat 10 download page:

Users of Tomcat 10 onwards should be aware that, ..., the primary package for all implemented APIs has changed from javax.* to jakarta.*. This will almost certainly require code changes to enable applications to migrate from Tomcat 9 and earlier to Tomcat 10 and later.

So use Tomcat 9 instead of 10.

Upvotes: 3

SuBZ
SuBZ

Reputation: 11

java.lang.NoClassDefFoundError: javax/servlet/ServletContextListener for this NoClassDefFoundError on HttpSessionListener , ServletListener , ServletContextListener, etc. can be caused by a custom classloader like Sysdeo DevLoader (when using it with Eclipse) in you Context definition in the Tomcat’s server.xml file.

<Loader classname="org.apache.catalina.loader.DevLoader"
        reloadable="true" debug="1" />

there.....insted of this use...

<Loader classname="org.apache.catalina.loader.DevLoader" 
        reloadable="true"
        debug="1" useSystemClassLoaderAsParent="false"/>

and add DevLoader.jar to ur class path

Upvotes: 1

BalusC
BalusC

Reputation: 1109432

As per its javadoc that class was introduced in Servlet API version 2.3.

If you're receiving this error, then it can have basically three causes:

  1. Your web.xml is declared as Servlet 2.2 or lower (or incorrectly declared; Tomcat may fall back to least compatibility modus). Since you're using Java EE 5 and thus Servlet 2.5, the web.xml should then be declared like as:

    <web-app 
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    id="YourWebAppID" version="2.5">

  2. Your servletcontainer doesn't support Servlet 2.3 at all and will fall back to least compatibilty modus. But this can be excluded since Tomcat 6 should support Servlet 2.5.

  3. You actually have another Servlet API JAR file of an ancient version in the classpath which is taking precedence in classloading. Since you already excluded WEB-INF/lib the next places to look would be JRE/lib and JRE/lib/ext folders.

Update: as per your edit, FilterChain was also introduced in Servlet API version 2.3.

1 + 1 = ... :)

Upvotes: 4

Stephen C
Stephen C

Reputation: 719386

@BalusC's explanation sounds more plausible than mine ...

Some other possible explanations / things to check:

  1. The servlet-api.jar is not in $CATALINA_HOME/lib, or for some reason doesn't contain the class. (I know you said you "know" it's there, but you didn't specifically say you checked it.)

  2. Something else is broken which caused the first attempted load of HttpSessionListener to fail with an uncaught exception during static initialization. (This is kind of implausible, since HttpSessionListener is an interface. But it is worth checking the logs for earlier class loading errors ... just in case.)

  3. The missing class might be named foo.bar.HttpSessionListener rather than javax.servlet.http.HttpSessionListener. This is likely to show up in the nested stack trace.

  4. If something in the WAR you are deploying is creating its own classloader, it is possible that is is doing this incorrectly and the HttpSessionListener class is not on the classloader's effective classpath.

EDIT

If you are now seeing unresolved compilation errors reported in the logs, you should be suspecting the WAR file and the process used to build it. Specifically, it sounds like the WAR includes classes that had Java compilation errors!

(Or maybe this is a problem compiling JSPs ... but that would show up in the logs too.)

Upvotes: 3

Related Questions