[pjacob]

Hi all,

I’m using MyEclipse 4.1M1 and Tomcat 5.5.12 to develop a web application.
I have a problem that is driving me nuts: Hot code replacement/reloading for JSP’s is not functionning.

The Host element in server.xml has the autoDeploy=”true” set.
<Host name=”localhost” appBase=”webapps”
unpackWARs=”true” autoDeploy=”true”
xmlValidation=”false” xmlNamespaceAware=”false”>

The application has a /META-INF/context.xml file where I set the reloadable flag to “true”:
<Context docBase=”/bimat” reloadable=”true” debug=”5″
antiResourceLocking=”true” antiJARLocking=”true” cachingAllowed=”false”>
</Context>

The application is deployed as an Exploded Archive under ${TOMCAT_HOME}/webapps/bimat.

The application has a very simple JSP under web-root/testjsp.jsp that I use to test JSP’s hot code replacement.

When I edit and save the JSP I can clearly see that MyEclipse copy the new file version into tomcat’s deployment directory as ${TOMCAT_HOME}/webapps/bimat/testjsp.jsp because the JSP’s file’s modification date is updated.

The fact is: the file ${TOMCAT_HOME}/webapps/bimat/testjsp.jsp is now newer the the compiled version in ${TOMCAT_HOME}\work\Catalina\localhost\bimat\org\apache\jsp\testjsp.class.

Nevertheless, when I hit the refresh button on my web browser I still receive the old compiled version (I can see that Tomcat is not recompiling the JSP because the request is processed almost instantly whereas when Tomcat is actualy compiling the JSP the request would have take two or three seconds to complete)

My Question is: Isn’t Tomcat suposed to detect that the JSP source is newer that the compiled version and then automaticly recompile the JSP from the newer source and reload it ???

Is there a magic trick somewhere to know ?

[Riyad Kalla]

All of your settings are exactly right, and thank you for being so detailed with your post.

Before we go crazy here trying to figure out what is going on, try and download Tomcat 5.5.9, unzip it to a new (temp) location and set it up in MyEclipse. Now deploy and run your app there as an exploded app, does it work correctly?

[zartc]

I found the problem and its solution.

The Tomcat 5.5.12 documentation is simply *wrong* !

In various place (here http://tomcat.apache.org/tomcat-5.5-doc/appdev/deployment.html chapter “Tomcat Context Descriptor” and here http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html#A%20word%20on%20Contexts) the documentation says that TOMCAT 5.5.x is now reading the application context descriptor from the xml file /META-INF/context.xml.

From reading the documentation you can grow the assurance that the file must be nammed “context.xml” … why not, it certainly make sense … but it doesn’t work !

The file must be named after your application name. That is if your application is deployed as “/foo-bar” then the file must be named /META-INF/foo-bar.xml. In my case my application is deployed as “/bimat” thus the file must be /META-INF/bimat.xml.

Renaming the file is the magic trick I was looking for. Now TOMCAT reload my JSPs as soon as I save them, I no longer have to redeploy the whole thing – life is great again 🙂

I realy like this trick to be included in a FAQ of some sort as I can imagine the number of poor developpers that will be trapped by this realy nasty documentation bug.

[Riyad Kalla]

I think you just uncovered the answer to a 3-year long question of mine, very nice zartc!

[zartc]

There is a drawback still.

It is now impossible to redeploy using MyEclipse Project Deployement Manager.
Each time I hit the ‘Redeploy’ or even the ‘Remove’ button I get a warning message:
“Deployment is out of date due to changes in the underlying project contents. You’ll need to manually ‘Redeploy’ the project to update the deployed archive.”

Then TOMCAT is complaining that the web.xml is not present… Hitting the ‘Browse’ button show a deployment directory almot empty except for the libraries that are still there. My gess is that MyEclipse removed all the file it could but failed to remove some libraries because they are in use.

This is a long standing problem that is normally corrected by specifying
antiResourceLocking=”true” antiJARLocking=”true”
in the context element of the “/META-INF/<your_context_name>.xml” file.

Could it be that TOMCAT is not reading the context element ??

I’ll investigate.

[Riyad Kalla]

1) Don’t redeploy your app to a running app server
2) Yes using anti locking *should* work
3) If you areu sing an exploded deployment, you shouldn’t ever need to redeploy manually. Why are you needing to do this?

[Joey Geiger]

How would this solution work for someone using their webapp as the root of a site?

I don’t have a “/META-INF/<your_context_name>.xml” or “/META-INF/context.xml” with my webapplication as I’ve got it specified within the <host></host> section of my server.xml.

<Host name="x" appBase="C:\web\x"
       unpackWARs="true" autoDeploy="true"
       xmlValidation="false" xmlNamespaceAware="false" reloadable="true">

   <Context path="" docBase="" debug="1" />

</Host>

I *think* it’s working with hotcode replacement, but I just would like to make sure for future projects where I may not have the ability to modify the server.xml.

[zartc]

Just a follow through.

Contrary to what I was saying a few month ago, the tomcat doc is definitively *right*, the context file have to be named: /META-INF/context.xml I have no doubt about this anymore. 😳

The problem of Tomcat not reloading modified JSP was comming from the antiResourceLocking=”true” setting in my /META-INF/context.xml. Setting this attribute to true has the bad side effect of disabling JSP auto-reloading (This has been referenced as bug 37668: http://issues.apache.org/bugzilla/show_bug.cgi?id=37668 and the Tomcat has been updated to mention it: http://tomcat.apache.org/tomcat-5.5-doc/config/context.html).

The explanation of the behavior I was encountering is faily simple:
1) I had rename my /META-INF/context.xml into /META-INF/myprojectname.xml
2) Tomcat, looking for a /META-INF/context.xml, did not find one, thus creates a new context file in $CATALINA_HOME/conf/[enginename]/[hostname]/[webappname].xml as explained here http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html#A%20word%20on%20Contexts
3) The context.xml file created by Tomcat did not set antiResourceLocking=”true” thus Tomcat was able to reload modified JSP.

Conclusion:
1. Your describe your context in the file /META-INF/context.xml (the Tomcat doc is absolutely correct about this).
2. Don’t set antiResourceLocking=”true” (set it to false, or don’t mentione it)

I hope this will definitively close the JSP reloading problem.

[Riyad Kalla]

zartc,
Your digging is extremely valuable, infact I’m going to add it to our FAQ section with proper credits. Thank you for following up with that information for everyone.

[medeny]

That was extremely helpful. However, I still have a problem with reloading jsps…

Namely, this is what I found out is happening. It started since I cleaned up the machine and reinstalled tomcat. The thing is, I don’t keep my files in the webapps directory because it’s under source control somewhere else on the drive. It used to work perfectly before reinstallation – I just deployed the application from the source control folder (jsps with the WEB-INF/classes in there as well). When I updated a jsp, I could refresh and see the result without having to restart. What I noticed with Tomcat 5.5 now is that when I deploy the application, it actually copies all the files in my app foder to the webapps folder! Hence, when I update jsps now, it’s a different file so of course it doesn’t propagate. Updating the copied file in webapps shows up without restart just fine.

Does anyone know how to setup tomcat or deploy the app so it does not copy the files over (my setup before i reinstalled the machine did just that so i know it’s possible, or that it was with that version anyhow). Help greatly appreciate because this is really anoying and it kills productivity.

Thanks!

[Riyad Kalla]

medeny,
It sounds to me like with your old setup you had your context in Tomcat setup to point directly at your project directory, so even a deployment was totally unnecessary. Does this sound right?

[medeny]

Hm maybe but I’m not even sure I understand contexts or know how to set them up, i.e. I didn’t do anything special in my old setup except use the Tomcat’s Manager webapp UI to deploy my application from its location. Given what you said, can you, and if so, how can you setup tomcat to point directly to an arbitrary directory (outside of install_dir) and not copy files over to webapps when the app is deployed/used?

Thanks!

[Riyad Kalla]

I think you are making this a lot harder than it needs to be. The way it usually work is:

1) Download Tomcat ZIP file, unzip it somewhere
2) Setup the Tomcat connector in MyEclipse to point to that new dir, then go to the JDK setting and specify a JDK to run Tomcat with
3) Open your project if it’s not already open
4) Click the deployment manager in the toolbar, click Add then add a new “Exploded” deployment for your project to Tomcat
5) Start Tomcat and work away

As long as you are using an Exploded deployment AND have Window > Prefs > General > Workspace > “Build automatically” selected, as you save files MyEclipse will immediately sync them out to your server for you.

So say you are editing index.jsp, you work some, hit save, alt-tab over to your browser and hit refresh. Alt-tab back to MyEclipse, make some more changes, hit save again, alt-tab back and refresh again to see your changes.

This is a typical work cycle using Tomcat and Exploded deployments with MyEclipse.

Does that sound like what you wanted? This is the easiest, you don’t need to muck with any fancy app server settings or the Tomcat deployment manager.

[medeny]

Thanks Riyad, that was very helpful.

I also got it working by adding a context child to the host in server.xml as opposed to using the manager to deploy the application through UI.

[Author]

Posts