my dog learned polymorphism*
The moose likes Tomcat and the fly likes Tomcat weirdness -- incomplete WAR explosion, display of out-of-date (cached?) JSP Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Tomcat weirdness -- incomplete WAR explosion, display of out-of-date (cached?) JSP" Watch "Tomcat weirdness -- incomplete WAR explosion, display of out-of-date (cached?) JSP" New topic

Tomcat weirdness -- incomplete WAR explosion, display of out-of-date (cached?) JSP

James Adams
Ranch Hand

Joined: Sep 12, 2003
Posts: 188
I am developing a Spring MVC and Hibernate application and deploying it on Tomcat 5.5 running on a Windows XP machine. I am having several problems which I can't make any sense of (I've searched for hours for clues/answers), so I'm hoping someone here can shed some light.

1) I am building and deploying the WAR for this application using Ant, which is being run from Eclipse. When the WAR is deployed to $TOMCAT_HOME/webapps it fails to explode properly, and all that is left in my application's directory after redeploy is WEB-INF/lib/ehcache-1.1.jar. However if I stop Tomcat, remove the application directory (but not the WAR), and then restart Tomcat then the WAR is properly exploded and all files and libraries are where they should be.

2) I have a JSP page which is used as a view returned by a Spring MVC Controller. The page originally just displayed some text, but now uses JSTL tags to iterate over the model returned by the Controller. When I enter the URI which maps to the Controller I get one of two responses, apparently randomly. The most common is that the current JSP is processed, and Tomcat croaks with an error message telling me that the JSTL URI can't be resolved. At other times I get the previous version of the JSP, which just displays a dummy string. This old version of the JSP is no longer present in the WAR or anywhere under the the $TOMCAT_HOME/webapps directory, so I can only assume that it is coming somehow from my browser's cache, even though I have repeatedly cleared the cache. The above happens when using both IE and Firefox. So this is actually two problems in one -- not being able to resolve the JSTL URI and sporadically displaying an out-of-date and nonexistent JSP.

Does any of the above point to a configuration issue in Tomcat? I have made no configuration changes at all since installing the fresh installation of Tomcat 5.5.

Thanks in advance for any suggestinos or insight!

James Adams
Ranch Hand

Joined: Sep 12, 2003
Posts: 188
I think the problem with the JSTL URI not being resolved had to do with the absence of standard.jar in the WEB/INF/lib directory. Now that this JAR is there I no longer have the problem of JSTL URI being unresolved, nor does the old JSP ever get displayed.

I still have the WAR explosion problem though, so if anyone can comment on that I'd appreciate your insight.

Victor Thomson

Joined: Aug 23, 2005
Posts: 5
I'm also experiencing problems deploying a war with ant. The first thing I noticed was than in my deploy task, if the path attribute is set to something more than just a top level directory (eg /dir/subdir vice just /dir), then I get a deploy error. It looks like path is not meant to be used to set the context for the webapp. Soooo, I opted to use a context.xml file, war'ed in the META-INF directory. However, when you deploy this war you get a different error with the webapp not being deployed properly. See this post:

Are you doing either of these? I'm also using the latest Tomcat in the 4.1.x series....

Consider Paul's rocket mass heater.
subject: Tomcat weirdness -- incomplete WAR explosion, display of out-of-date (cached?) JSP
Similar Threads
when configure tomcat new Context tomcat creates me 2 web apps
Advice on deploying WAR file
in tomcat which one has to start first?
Default JSTL URI can't be resolved
Deploying a servlet to a Tomcat server I don't own