Launching and Debugging Tomcat in Eclipse
Modern IDEs like Eclipse provide various Plugins to ease web developement. However, I believe that starting Tomcat as "normal" Java application still provides the best debugging experience. Most of the time, this is because these tools launch Tomcat or any other servlet container as external process and then attach a remote debugger on it. While you're still able to set breakpoints and inspect variables, other features like hot code replacement don't work that well. Also, plugins like Eclipse WTP don't really improve the startup time, stability and memory footprint of Eclipse ;-)
Therefore I prefer to start my Tomcat just like any other Java application from within Eclipse. Here's how it works:
This article addresses experienced Eclipse users. You should already know how to create projects, change their built path and how to run classes. If you need any help, feel free to leave a comment or contact me.
We'll add the Tomcat as additional Eclipse project, so that paths and all remain platform independent. (I even keep this project in our SVN so that everybody works with the same setup).
Step 1 - Create new Java project named "Tomcat7"
Step 2 - Remove the "src" source folder
Step 3 - Download Tomcat (Core Version) and unzip into our newly created project. This should now look something like this:
Step 4 - If you havn't, create a new Test project which contains your sources (servlets, jsp pages, jsf pages...). Make sure you add the required libraries to the built path of the project
Step 5.1 - Create a run configuration. Select our Test project as base and set org.apache.catalina.startup.Bootstrap as main class.
Step 5.2 - Optionally specify larger heap settings as VM arguments. Important: Select the "Tomcat" project as working directory (Click on the "Workspace" button below the entry field.
Step 5.3 - Add bootstrap.jar and tomcat-juli.jar from the Tomcat7/bin directory as bootstrap classpath.Add everything in Tomcat7/lib as user entries. Make sure the Test project and all other classpath entries (i.e. maven dependencies) are below those.
Now you can "Apply" and start Tomcat by hitting "Debug". After a few seconds (check the console output) you can go to http://localhost:8080/examples/ and check out the examples provided by Tomcat.
Step 6 - Add Demo-Servlet - Go to our Test project, add a new package called "demo" and a new servlet called "TestServlet". Be creative with some test output - like I was...
Step 7 - Change web.xml - Go to the web.xml of the examples context and add our servlet (as shown in the image). Below all servlets you also have to add a servlet-mapping (not shown in the image below). This looks like that:
<servlet-mapping>
<servlet-name>test</servlet-name>
<url-pattern>/demo/test</url-pattern>
</servlet-mapping>
Hit save and restart tomcat. You should now see your debug output by surfing to http://localhost:8080/examples/demo/test - You now can set breakpoints, change the output (thanks to hot code replacement) and do all the other fun stuff you do with other debugging sessions.
Hint: Keeping your JSP/JSF files as well as your web.xml and other resources already in another project? Just create a little ANT script which copies them into the webapps folder of the tomcat - and you get re-deployment with a single mouse click. Even better (this is what we do): You can modify/override the ResourceResolver of JSF. Therefore you can simply use the classloader to resolve your .xhtml files. This way, you can keep your Java sources and your JSF sources close to each other. I will cover that in another post - The fun stuff starts when running multi tenant systems with custom JSF files per tenant. The JSF implementation of Sun/Oracle has some nice gotchas built-in for that case ;-)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)














Comments
Mark Priest replied on Wed, 2012/02/08 - 11:24pm
I set up the Run config for my application a lot like you do with bootstrap and runtime tomcat libs and org.apache.catalina.startup.Bootstrap as the main class. But I add the catalina properties like this:
-Xmx512m -Dcatalina.home="C:\Program Files\Apache Software Foundation\Tomcat 6.0" -Dcatalina.base="C:\dev\vs\common\src\main\tomcat"Note that this way I don't need to worry about the working directory setting in Eclipse.
Nicolas Frankel replied on Thu, 2012/02/09 - 2:23am
in response to:
Mark Priest
John Dough replied on Thu, 2012/02/09 - 2:39am
Andreas Haufler replied on Thu, 2012/02/09 - 2:59am
Mark, I think we're pretty much doing the same. The main benefit of copying Tomcat into the workspace is, that it is the same on all developer machines (We share the run configuration via git). Of course you also can also agree on a common directory like your 'c:\dev' - as long as everyone is using the same OS, which of course would be a sane choice.
Nicolas, the point is, that you get a much better integration as you get with WTP - as fas as my experiments are concerned. Also, I wrote a pretty much detailed description. I do this setup way quicker, than making my way through the Eclipse update sites and the marketplace. Also, since we share this in git, I do this setup once and every other developer simply checks out the project, hits the run button and can use tomcat along with full debugging capabilities in seconds. Far easier than keeping all Eclipse installations in sync. However, it is just one approch, I you like WTP, feel free to use it, it's not that I'd consider that a crime ;-)
Cosmin Mutu replied on Thu, 2012/02/09 - 3:12am
Nicolas Frankel :
+1 : too much trouble, not to mention that you now have a special project named TOMCAT in your workspaceIvan Lazarte replied on Thu, 2012/02/09 - 2:35pm
Stephanie Kaye Lopez replied on Wed, 2013/01/23 - 7:49am
One aim of the IDE is to reduce the configuration necessary to piece together multiple development utilities, instead providing the same set of capabilities as a cohesive unit. Reducing that setup time can increase developer productivity, in cases where learning to use the IDE is faster than manually integrating all of the individual tools. Tighter integration of all development tasks has the potential to improve overall productivity beyond just helping with setup tasks. -Ron D. Smith