How do I make Tomcat stop caching my servlet responses?

Question

I'm learning Servlets programming, using Apache Tomcat 6 on a Ubuntu 8.10 machine, and I'm running with a very annoying issue -- apparently, related to caching.

This is what I'm doing: I write a servlet, put it in a nice directory structure and deploy it using the Tomcat Web Application Manager. It works as expected. Then I edit the servlet, recompile and try to access it again, but Tomcat keeps returning the same old version. Reloading the Application or even restarting the server does not work. The only thing that works is "Undeploying" the Application, then deploying it all over again.

I have to do this every single time I make any small change on my code. It sucks.

I'm sure there is a way around this, but I couldn't find the answer anywhere on the web (and I did search a lot). I would really appreciate any help. Thanks!

Solution 1

The advice from Adeel Ansari is flawed: you should never modify CATALINA_HOME/conf/context.xml with webapp-specific configuration. That's what your-webapp/META-INF/context.xml is for.

You should also never specify the "docBase" attribute of <Context>. You should also never specify the "path" attribute of <Context>.

The OP has several options:

1. Use the manager to reload the web app (undeploy/redeploy should not be necessary: a simple reload should work) ( http://tomcat.apache.org/tomcat-6.0-doc/manager-howto.html#Reload_An_Existing_Application )

2. Set the element in META-INF/context.xml to have reloadable="true" ( http://tomcat.apache.org/tomcat-6.0-doc/config/context.html )

With all due respect to SO, if you need help with Tomcat, join the users' mailing list and get some real answers.

Solution 2

Under your TOMCAT_HOME/conf/, you will find a file named Context.xml. The content would look like below,

<Context>
    <!-- Default set of monitored resources -->
    <WatchedResource>WEB-INF/web.xml</WatchedResource>
    <WatchedResource>WEB-INF/classes</WatchedResource>
</Context>

Both lines are uncommented here, you should uncomment both too. Its likely that you will have the 2nd one commented or might not have it at all. Try uncomment it, or add it in latter case. I am assuming you are deploying your app under TOMCAT_HOME/webapps.

[Edited]

Try using docBase, and path attribure under your Context element. Below is the example

<Context docBase="path-to-WEB-INF" path="/your-app">

NOTE: Don't include WEB_INF

[Edited]

May be I am missing something. Check this out. Its the same, but much more clear and descriptive including few other options.

Solution 3

I have encountered similar problems with Tomcat 5.5. I never figured out the root cause but I worked around it by deleting the folder corresponding to the webapp from %CATALINA_HOME%/work/Catalina/localhost. Its not a great solution but it avoids you having to undeploy/redeploy your whole application.

Solution 4

You don't say if you are using the ubuntu tomcat or a separate download from tomcat.apache.org. If you are using the ubuntu one, try to make it simpler with using a separate download. The standard download is very easy to administer and rather geared to working out of the box. It might be (I don't know) that the ubuntu one might be configured more towards production use, e.g. it might be somewhat hardened.

The recommended production setting for tomcat is just what you describe (e.g. no auto-deploy etc). The development setting is way easier to use.

View more solutions

Comments

[Adeel Ansari]

That will work indeed. Actually that directory works a cache. So, deleting that, will solve the problem. But sometimes you mind deleting it every time, you test.

[Admin]

I found context.xml at CATALINA_BASE/conf/ (the default homepage on localhost:8080 tells me about CATALINA_HOME and CATALINA_BASE, I'm not sure if that's the same as TOMCAT_HOME). Anyway, I added the second line, restarted the server, but with no results :-(

[Admin]

BTW, I'm using the Web Application Manager to deploy (and undeploy) it -- as I understand it, it is going under CATALINA_BASE/webapps.

[Adeel Ansari]

Yes, CATALINA_HOME or BASE is the same. Are you using netbeans? Do you have a separate context file for your app? I mean <your-app>.xml

[Admin]

I'm not using Netbeans. The only XML file I have is web.xml.

[Adeel Ansari]

No, it wouldn't. You need to build it and then re-deploy it, in order to see the change. And he/she doesn't want to re-deploy. Compiling the source is different and depends on IDE settings.

[Admin]

It just tried it, still doesn't work. I'll read the docs on the link you provided, see if I can figure it out.

[Adeel Ansari]

It might be caching things somewhere else. Or are you not having any JSPs or never requested any for the time being. Because /work/Catalina/localhost/... is a directory compiled JSPs are kept, not the servlets or other classes.

[Brian Warshaw]

I tried this and it worked for me. Added a delete task as part of my ant task that deploys to tomcat, and it works a treat.

[Petr Gladkikh]

"you should never modify CATALINA_HOME/conf/context.xml with webapp-specific configuration." - how do you provide container specific parameters without application recompilation then? Does it suggest that one should build new version of application for every deployment environment?

[Christopher Schultz]

@PetrGladkikh I would suggest that all configuration required for a web application be bundled in the WAR file and not hidden in some other place (like conf/context.xml). Defining JNDI DataSources is appropriate for server.xml and then using <ResourceLink>, but you don't want to modify the default configuration for all webapps on the entire container by modifying conf/context.xml.

[Jacek Cz]

agree with @PetrGladkikh and apologize answer of Christopher Schultz. Official documentation has page about defining something in catalina context.xml and deriving in aplication xml. First is in hands of Admin , the next Programmer. This is very useful technique, give good possibilities (separate ranges) for both

[xpusostomos]

This is bizarre advice. The whole point of changing context.xml is so that you can deploy the same war to different servers with different configurations.

[Christopher Schultz]

@xpusostomos There are two context.xml files. One of them is global for every application deployed on that Tomcat instance and the other is private to a single application. I'm advocating to use the application-specific one instead of the global one.