views:

1857

answers:

4

I used to run Tomcat separately on my machine. I had an Ant script that would rebuild my project, deploy it locally, and restart Tomcat. That all worked ok, but I wasn't able to debug the web app inside Eclipse.

So I learned how to setup Tomcat inside Eclipse and got my web app running. Now the problem is that I don't understand fully how to manage it this way. Eclipse is set to automatically build my project on changes, but those changes don't seem to always be reflected in the web app. Sometimes I have to manually build the project and manually "clean" the server for the changes to be reflected.

Are there rules somewhere about how to manage this setup? For instance, if I only change a JSP then will it automatically be synchronized? If I change a servlet class, then I need to manually rebuild the project? Are these rules consistent, or should I just manually rebuild and clean every time?

I would really appreciate it if someone could give me the best practice rules or point me to a good resource to learn how to manage this environment.

PS. I am using Eclipse 3.4.1 JEE package and Tomcat v5.5

A: 

Normally you should republish the application to get latest changes, don't forget to synchronize with file system first in case your files modified extrernally. You can specify that your application is automatically reloaded when modified, look for Auto-reload attribute in server.xml of your server configuration project. When set to true, tomcat will automatically reload your application. It's not always a good idea by the way. Modified JSP's should work automatically, no need to restart the applciation.

Dima
A: 

If you change the structure of a class that has already been loaded and used (add/remove members, change method signature etc.) your code changes will not be reflected. This is not an eclipse issue but a JVM issue. If you make simple code changes, like logic changes inside an existing method, your changes will take effect after the class is compiled and re-deployed. Regardless of that, if you change a public constant, you have to rebuild your project(s).

Shai
+1  A: 

You can use Eclipse and Tomcat in the way you mention. First the basics of how to set it up:

  1. In the Servers view setup a new Tomcat server pointing to your TOMCAT_HOME
  2. Make sure your project is an Eclipse "web project". You may need to create a dummy one and copy over some of the files in .settings (look at the wst files).
  3. Deploy your project to Tomcat by right clicking on the server in the Servers view and "Add and Remove Projects..." to add your project to the server.

You can run your server and test it out just like you were running Tomcat outside of Eclipse. If you run the server in Debug mode you can set breakpoints and step through the code.

As for when you will need to restart the server Eclipse is usually pretty good about auto-deploying the changes. You will pretty much never need to restart for changes to jsp pages. If you change a class it will auto-deploy the change (usually) if you change the body of a method. If you change the signature of a class (add or remove a method or change args for it) you will almost always need to restart. Any changes to configuration files (web.xml or similar) will also almost always require a restart.

To restart just click on the "Debug" or "Run" button in the Server view. All your changes will be redeployed into Tomcat.

One thing to watch out for is that in the default configuration your "webapp" directory in TOMCAT_HOME will not be used. Instead it will use a folder under your Eclipse workspace directory (WORKSPACE/.metadata/.plugins/org.eclipse.wst.server.core/tmp0).

John Meagher
A: 

I found two things important to understand:

  • Eclipse does not automatically realize if files were changed outside of Eclipse. clicking Refresh on a project does that, so does F5. You can also change a setting to refresh automatically, which, however, does not detect changes instantly (my gut feeling says up to 10 secs delay)

  • Working with servers has the concept of "Publishing" files to Tomcat. This normally happens automatically within a second after any change. Changing many classes can cause many server reloads, which can be a drag if a context reload takes some time (as complex Spring apps certainly do). So I changed a setting to not publish automatically (double-click Server instance)

Tom