This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

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

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 cannot be resolved
The import cannot be resolved
The import 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: 18713
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.
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!