views:

110

answers:

3
+2  A: 

This is a sign of classpath pollution. The JSP/Servlet API libraries are appserver implementation dependent and belongs in case of Tomcat 6 in the Tomcat/lib folder and should in no way be moved nor duplicated somewhere else. It's receipt for portability trouble and collisions in classloading as you've encountered now. The libraries in webapp has precedence in classloading. If the servlet-api.jar is encountered there, it is in turn looking for its dependencies, but they were apparently missing in there.

You must remove any appserver-specific libraries from the webapp's Webapp/WEB-INF/lib. You should only put webapp-specific libraries in there. Keep appserver-specific libraries in the appserver's default classpath, which is the Tomcat/lib in your case. Keep it untouched. You can at highest add libraries which you'd like to share among all webapps in there, or even better, configure the shared.loader in Tomcat/conf/catalina.properties.

Also remove any appserver-specific and webapp-specific libraries from the JDK/lib and JRE/lib folders, if any. I've seen too often that some move/copy the libraries there because "it otherwise doesn't compile". You should never copy libraries in there. It is receipt for portability trouble as well. When compiling classes with javac, you should use the -cp argument to specify the dependency libraries.

Update: in case of an IDE (you seem to use one as you're talking about "build path"), you need to associate the web project with an application server. In Eclipse for example, you have the option to do that during creation of a Dynamic Web Project. You need to integrate the server instance in Eclipse prior to project creation. You can do that through the Servers view (assuming that you're using Eclipse for Java EE developers, else upgrade). You can also change it afterwards through the Servers entry in the project properties. Choose one which you'd like to use as the "default" server and then its libraries will automagically be included in the project's build path. There's absolutely no need to copy/move them somewhere else.

BalusC
Thanks your update sounds like it will do the trick
Ankur
Unfortunatley it didn't work :( will keep looking
Ankur
Assuming that you mean that you still get the same problem, then you need to ensure that you cleanup the classpath as I explained in the first three paragraphs of my answer.
BalusC
+1  A: 

The first error message you got was because Tomcat doesn't need to load the servlet jar because it already has one and wants to avoid conflicts.

You can usually safely ignore the warning. If you don't want it to appear, you need to move the servlet jar from your project, rather than using the one from tomcat. By taking the tomcat one and putting it into your project, you've managed to convince tomcat to load it from your webapp rather than from from where it was expecting it, causing a classloader issue as mentioned in the BalusC's answer.

Edit: The above was edited to clarify what was happening once you put the servlet-api jar from tomcat into your webapp (and attribute BalusC).

jamie mccrindle
This is not a warning. This is an error.
BalusC
The second stacktrace is definitely an error. The first one is an INFO message. It may be a problem in this case but I've seen this before in projects that I've deployed and Tomcat has merrily continued after ignoring the jar.
jamie mccrindle
Ah okay, an info message is still not a warning message :)
BalusC
Haha, yeah, ok. How about we call it a draw :)
jamie mccrindle
+1  A: 

You are not allowed to deploy classes that override those defined in the Servlet Specification to be provided by the web container. You can download the specification from

http://www.jcp.org/aboutJava/communityprocess/final/jsr053/

and check for yourself. Section 9.7.2 is on physical page 63.

Servlet 2.3 is a rather old version indicating an ancient version of Tomcat. Is there any particular reason you are not using a newer one?

Thorbjørn Ravn Andersen
Please excuse my ignorance, but I am using Java 6. Is the servlet spec going to be independent of this. You see the code was written by another group and I am trying to deploy the application so maybe the did something that is causing it to use Servlet spec 2.3 ? Not sure if this makes sense.
Ankur
Yes. Java is aggressively backwards compatible. You most likely can just remove the servlet.jar from WEB-INF/lib as they probably left it in by mistake or ignorance.
Thorbjørn Ravn Andersen