Eclipse Zone is brought to you in partnership with:

Andreas Haufler is the software architect and one of the founders of the scireum GmbH, loacted near Suttgart (Germany). He holds a Diploma in Computer Science (Softwareengineering) from the University of Stuttgart. He has over ten years of experience with Java, HTML and related web technologies. Being a "language hobbyist" he is also interested in enjoying the power of less popular but definitely more beautiful lanuages like Smalltalk and Lisp(s). Andreas has posted 6 posts at DZone. View Full User Profile

Launching and Debugging Tomcat in Eclipse

02.08.2012
| 34709 views |
  • submit to reddit

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 ;-)

Published at DZone with permission of its author, Andreas Haufler.

(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 find it convenient to run Tomcat as part of my application project. I have Tomcat installed on my system and then I use catalina home and catalina base properties to tell Tomcat where to find its own configuration and also my app's configuration. That way I don't have to copy things over to Tomcat as they are already there. This actually mirrors the way our app is installed. We install Tomcat and then set catalina base to point to our app install location.

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

Sorry, but I fail to see your point here: going to a lot of trouble just not to install WTP is a bit convoluted for me. If you're going this way, why use an IDE at all. I had problems with WTP (and still have), but Tomcat's integration is the best I've seen so far.

John Dough replied on Thu, 2012/02/09 - 2:39am

Good article - thanks!

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 workspace

Ivan Lazarte replied on Thu, 2012/02/09 - 2:35pm

Tomcat was my preferred servlet container until I tried embedded Jetty - just a jar file and a main class you code to start it. POJF? Plain ole Jar File? It doesn't get any easier. Plus you can start doing fancy stuff super easily, like making a full regexp controller in about 5 lines of code and not be burdened by web.xml or any of the other crap. Suddenly the springframework is the container! It makes SO much more sense this way.

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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.