- This topic has 1 reply, 2 voices, and was last updated 19 years ago by
.
-
Posts
-
Hi,
I’m using Tomcat 4.1.31 and MyEclipse 4.0.3. I’ve set up the Tomcat 4 application server to point to my Tomcat installation for deployment of Web Projects.
Am observing the following during my development of a web application:
Whenever I make changes to my JSP files, the changes are reflected real time.
However the changes I make to my Java files doesn’t seem to get populated to the server real time. In additional, if I then try and redeploy the application via the Re-deploy option, MyEclipse tells me this:
Deployment is out of date due to changes in te underlying project contents. You’ll need to manually ‘Redeploy’ the project to update the deployed archive.
I then needed to stop the server, re-deploy (I don’t get the message above if I stop the server) and then re-start the server to see the changes.
Are these observations because of limitations with Tomcat 4.1, or due to some set-up mis-configuration that I need to correct with my copy of MyEclipse?
What is happening are two things. First, the Eclipse debugger compiles your Java class and attempts to update it into the remote JVM using hot code replacement, as supported by the 1.4 JPDA spec. Second, Sync-on-Demand updates your Java file to all your deployment locations.
The error you’re seeing is a failure of step one because you’ve modified the class in such a way that hot code replacement is currently unsupported by the JVM. The basic rule is that for hot code replacement to work, you can’t change the “shape” of the class. This includes adding methods, member variables, etc. This will get better in the future as the debugging spec matures, but that’s where the limitation now is.
Since Sync-on-Demand has already made sure that the deployment class has been updated, you’ll simply have to stop and restart the application server after making a change in a Java class that isn’t supported by hot code replacement.
The other problem is that Tomcat likes to lock Jar files while running and this hampers the ability to redeploy. However, a workaround for that is available here:
http://blog.exis.com/colin/archives/2005/08/23/i-put-a-spell-on-you-because-youre-mine-aka-why-is-tomcat-holding-onto-jars/See antiJarLocking/anitResourceLocking at:
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html
