• Post Reply Bookmark Topic Watch Topic
  • New Topic

Tomcat7 can't find classes in WEB-INF/lib/lookHere.jar

Alex Ryan
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Very weird problem with Tomcat7. I migrated some data objects out of my web app and into a jar file. Everything works fine when I deploy to tomcat7 on my local development machine. However, when I try to deploy the same code to test, tomcat cannot find the data object classes that have been migrated to the jar file. I don’t understand why this is happening. It’s almost as if tomcat is still expecting to find the data object in the web app and therefore isn’t even bothering to look in the jar file.

Does anyone know a way to FORCE tomcat to look in the WEB-INF/lib/lookHere.jar for the class files that it is not finding?

I’ve already tried clearing the working directory to no avail.

Here’s an example of the kind of errors that I’m getting when I try to invoke a servlet that utilizes one of these data objects:


java.lang.Error: Unresolved compilation problems:
The import com.alpine.data.http.gas.getStation cannot be resolved
The import com.alpine.data.http.message cannot be resolved
The import com.alpine.data.http.postDevicelogentries2 cannot be resolved
GetMessagesResponseRecord cannot be resolved to a type
The method getMessages(String, String, String, String) from the type MessageManager refers to the missing type GetMessagesResponseRecord

But the packages AND classes ARE THERE in the jar file !!!
I opened it up and validated them 1 by 1.
And the jar file is in the correct location.
And this DOES WORK with instance of tomcat I have on my development machine.

com/alpine/data/http/gas/getStations/ com/alpine/data/http/message/
Tim Holloway
Posts: 18415
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tomcat's web application classloader will automatically search all of the jar directories in a WAR's WEB-INF/lib directory. If it didn't, that would be a major violation of the J2EE/JEE standard.

What you are probably seeing is a stale copy of the webapp, from before the addition of the jar.

By default, when you deploy a WAR file to Tomcat's webapps directory, Tomcat will explode (unzip) the WAR into a webapps subdirectory with the same name as the WAR file (minus the ".war" extension). This then becomes the definitive copy of the webapp. Even if you deploy a new WAR file to the TOMCAT_HOME/webapps directory!!!. A new WAR file will not replace an older WAR directory.

To avoid that, it's a good practice to delete the old copies of the WAR and exploded WAR directory from TOMCAT_HOME/webapps and while you are at it, delete the contents of the TOMCAT_HOME/work and temp directories (while Tomcat is not running).

You can also avoid this problem by overriding Tomcat's default behavior of exploding WARs. That requires a setting in the TOMCAT_HOME/conf/server.xml file. Most people prefer the exploded WARs for debugging purposes, however.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!