The Power of Three - Eclipse, Tomcat, and Strutsby Keld H. Hansen

Introduction

As a programmer it's important to be productive, and as any other craftsman you need good tools to be productive. In this article I'll present a set of tools, which can really help you get your job done. What's more, they're all free, open source, and well documented. I've been using these tools in several real-life projects and have found that they often outdo expensive development tools. This is because they're simple to install, simple to use, reliable and have good performance.

The names of the tools are Eclipse, Tomcat, and Struts.

You've probably heard about all of them, and maybe you have used them in your work, but anyway: here's a short description of each:

Eclipse is an IDE from eclipse.org, which can be used for programming in Java and many other programming languages.

Tomcat is a J2EE web server from the Apache Jakarta project

Struts is a framework--also from Apache Jakarta--for building MVC-type servlet applications

So, these tools are made for making web applications based on the servlet specification. They don't cover EJB's, since Tomcat is not an EJB-server, and standard Eclipse does not cover EJB's.

Eclipse has a project type for Java development, but strangely enough not for Java web application development. A Java web application is characterized by a special directory structure (war-file structure), and a set of specialized files: jsp-files, XML configuration files, servlets, etc. To fill this gap, a very nice Eclipse plug-in from sysdeo.com is at hand. It not only gives us the web application project but also a way of managing the Tomcat server from within Eclipse. Below we'll see how to install and use this plug-in.

Struts gives you a way of building modular, de-coupled web applications. How Struts is included in Eclipse is another topic that'll be covered later in this article.

 

Install Eclipse

The first thing to do is to install Eclipse. I've chosen to use version 3.0M4 even if a newer version, 3.0M6, exists. This is because the Sysdeo plug-in explicitly states that it supports 3.0M4. Be warned: Eclipse is a rather large download: 69.1 Mb! You either need a speedy connection or a lot of patience.

Installation however, is a breeze. Unzip the downloaded file, locate the eclipse.exe in the download folder, double- click and you're off.

If you're not familiar with Eclipse, then use the built in documentation to get started. Select "Help" in the menu bar, and then "Help Contents".

Install Tomcat

The next step is to install a version of Tomcat. I've chosen the latest release, which currently is 5.0.16. Installation is as simple as Eclipse. You download a zip file and unzip it in a folder. On Windows you start Tomcat by opening a DOS window, and then run the startup bat-file from the bin directory. The environment variable JAVA_HOME must be set to the folder of your JDK, or the startup file will fail. I usually insert a line in the beginning of the startup file, and also the shutdown file, for example:

set JAVA_HOME=c:\j2sdk1.4.1_01

In order to be able to run the "admin" and "manager" programs in Tomcat you must define a user for this. Locate the tomcat-users.xml file in the conf folder, and insert this line:

<user username="admin" password="admin" roles="admin,manager"/>

Before proceeding you may want to start Tomcat to see if everything works. Run the startup bat-file from a DOS- window. This will bring up another DOS-window for Tomcat, and when it has completed initialization you'll see:

28-12-2003 13:10:40 org.apache.catalina.startup.Catalina startINFO: Server startup in 17005 ms

In a browser you may now enter

http://localhost:8080

which will show the Tomcat welcome page:

 

Install the Sysdeo Tomcat plug-in

Before installing the Tomcat plug-in you should stop Eclipse and Tomcat if they're already running.

There are a couple of Eclipse/Tomcat plug-ins available on the market. The most well-known, and the one we'll be using in this article, is the Sysdeo plug-in. The plug-in is available for several versions of Tomcat and Eclipse, and it's important to pick the one that matches your versions. For Eclipse 3.0M4 and Tomcat 5.0.16 you should use plug-in version 2.2.1. A complete list of all versions can be seen at this address: http://www.sysdeo.com/eclipse/tomcatPlugin.html. A release note file is available at http://www.sysdeo.com/eclipse/releaseNotesV221.txt, and you may find it useful to have a look at it, since it gives a feeling for the maturity and level of ambition for the sysdeo plug-in project.

The installation of the plug-in does not differ from other Eclipse plug-ins: After downloading the plug-in unzip it to Eclipse's "plug-ins" directory, and start Eclipse. It's possible to customize the use of the plug-in in various ways, which we'll see in the following. First of all you may verify that the plug-in has been installed by selecting Help/About/Plug-in Details from the menu (see the line at the bottom of this picture):

Customize the Sysdeo plug-in

You should now tell the plug-in where your Tomcat system is located. From the menu select Windows/Preferences/Tomcat and select

Tomcat version number Tomcat home (this automatically sets the configuration file)

Be sure to also enter data in the "Tomcat base" field, or you’ll not be able to run Tomcat applications like the Tomcat jsp examples or the Admin program.

Eclipse normally uses a JRE (Java Runtime Environment), and not a full JDK, but Tomcat must have access to a JDK. You should, therefore, first define a JDK for Tomcat. First select

Window/Preferences/Java/Installed JREs:

As you can see only a JRE is available. Press the "Add..." button to add a JDK to the list:

Pres the "OK" button and then check the new JDK:

This JDK must also be selected in Window/Preferences/Tomcat/JVM settings:

You complete the plug-in setup by entering the userid/password for the Tomcat Admin program:

 

The two main features of the Tomcat plug-in

What you have achieved now is first of all two things:

1. A new type of Java project, called a Tomcat project2. A way of starting and stopping Tomcat from within Eclipse.

The Tomcat Project Type

If you start to create a new Java project, you'll see the new Tomcat project as an option:

A Tomcat project is a Java project with the J2EE directory structure used in a war-file.

We'll create such a project and call it Tom1:

If you press the "Next" button you'll see this box:

The selection "Can update server.xml file" is important. Tomcat uses this file from the conf directory for various purposes. One of them is to locate projects that are not placed in Tomcat's webapps folder. By checking "Can update server.xml file" you allow the plug-in to add the Eclipse projects to the server.xml file. When we finish creating the Tom1 project we can therefore find this line in server.xml:

<Context path="/Tom1" reloadable="true" docBase="C:\eclipse3.04\workspace\Tom1" workDir="C:\eclipse3.04\workspace\Tom1\work" />

The path attribute is the name you use in the URL to address the application. The reloadable attribute chooses dynamic reloading of the application, and we'll discuss this option further below. DocBase tells Tomcat where to find the application, and workDir is a location for servlets to use.

The Tom1 project looks like this in Eclipse:

If you look in the Eclipse installation directory you'll see a matching directory structure:

Files in the Tom1 project should be placed in these folders:

WEB-INF/lib

html- and jsp-files Tom1

Java source files WEB-INF/src

Java class files WEB-INF/classes

Jar-files

When Eclipse compiles a Java class it knows that it should be put in the classes directory. This is actually a "property" of the project. Right-click on the Tom1 project and select Properties/Java Build Path/Source:

It's very important that the source folder and the output folder are set correctly for a project. The source folder does not need to be the WEB-INF/src folder, but the output folder must be WEB-INF/classes since this is the J2EE standard. The reason for the work folder also being set as a source folder is that Tomcat places the servlet code generated from jsp-pages here.

Starting and stopping Tomcat

We have two choices: to start up Tomcat outside or inside Eclipse. The difference between the two is, that if we want to use Eclipse's debug features on jsp-pages or Java classes, Tomcat must be started inside Eclipse. Debugging is of course a very important feature, so let's see how we manage Tomcat from Eclipse. First some customization (I assume that the Java Perspective is selected):

Select Window/Customize Perspective and then mark the Tomcat checkbox to get Tomcat in the menu and in the tool bar:

The menu and tool bar now looks like this, giving you two ways to start, restart and stop Tomcat:

If you now start Tomcat, you'll see the output from the start up process in Eclipse's console:

 

Debugging jsp-pages

Having everything set up we're now ready to see how debugging works. We'll start with a simple jsp page:

In the browser we enter this URL:

http://localhost:8080/Tom1/hello.jsp

If everything has been set up correctly you should see this:

It's also possible to debug a jsp-page, but unfortunately the plug-in does not work at the jsp-page level, but rather at the servlet-level. From the jsp-file Tomcat has generated a Java- servlet and compiled it. The result is found in the work- directory. Right-click on this directory in Eclipse and do a Refresh:

You may now open the generated Java file and set a breakpoint:

The blue circle marks the breakpoint. Now do a refresh in your browser. This will open Eclipse's debug perspective, and processing will halt at the breakpoint:

Remember that changes to the servlet code while debugging is not reflected in the jsp-pages.

Debugging servlets

To show you how debugging a servlet works, we'll create a very simple servlet:

A single breakpoint is already established. Before debugging can start we'll have to define the servlet to Tomcat. This can be done by creating a web.xml file and placing it in the WEB-INF folder:

<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>

<servlet> <servlet-name>HelloServlet</servlet-name> <servlet-class>HelloWorldServlet</servlet-class> </servlet>

<servlet-mapping> <servlet-name>HelloServlet</servlet-name> <url-pattern>/hello</url-pattern> </servlet-mapping>

</web-app>

The servlet can now be started with this URL:

http://localhost:8080/Tom1/hello

Another possibility is to define a generic rule for all servlets in Tomcat. This can be done in the web.xml file in Tomcat's conf directory. Remove the comments around the invoker servlet definitions:

<servlet> <servlet-name>invoker</servlet-name> <servlet-class>org.apache.catalina.servlets.InvokerServlet</servlet-class> <init-param> <param-name>debug</param-name> <param-value>0</param-value> </init-param> <load-on-startup>2</load-on-startup></servlet>

...and:

<servlet-mapping> <servlet-name>invoker</servlet-name> <url-pattern>/servlet/*</url-pattern></servlet-mapping>

You'll have to restart Tomcat if you do this modification. The "Hello World" application can now be started like this:

http://localhost:8080/Tom1/servlet/HelloWorldServlet

Having set the breakpoint above Eclipse will switch to the debug perspective and show the breakpoint:

In debug mode Eclipse offers many features, for example the possibility to inspect or even change the values of variables and objects. More information can be found in the Eclipse Help section: "Java Development User Guide".

Reloading applications

You'll remember that the Tom1 application was defined in the server.xml file with a reloadable attribute. This means that whenever Tomcat discovers a changed file in WEB-INF/classes or WEB-INF/lib it'll reload the application. This is necessary in order for the changed file to have an effect. Be prepared to wait a few seconds before the reload actually happens. Checking for changed files naturally takes some resources from the web server, so it should only be used in a development environment.

The reload can be seen in Eclipse's console window. Here I've added an exclamation mark to "Hello World", and saved the servlet:

The highlighted lines show that the reload process has taken place.

It's also possible to do a manual reload by right-clicking on the project, selecting "Tomcat project/Reload this context":

This kind of reload is the same as the one the Tomcat Manager can do for you with this URL:

http://localhost:8080/manager/reload?path=/Tom1

Whether or not a project is reloadable may be set in project properties. Right click, select Tomcat:

 

Adding Struts to the environment

Struts is a J2EE servlet framework, and hence needs the war-file directory structure that a Tomcat project builds. It's therefore a fairly simple task to build a Struts project. I assume that you have available a download of Struts version 1.1. If not it's available from this address: http://jakarta.apache .org/struts.

In the webapps folder of the download you'll find several example applications. Let's take struts-blank, which is the simplest among them.

First we define a new Tomcat project, called StrutsBlank by following the steps described previously. Then import the struts-blank war-file:

Click Next. Browse to the directory that contains the war file and type "*.war" in the File name field. Click "Open" to see all the war files:

Select struts-blank.war and click Open and Finish in the next box. This'll create a complete Struts project including all necessary jar-files, tag libraries, and configuration files. Only one thing needs to be changed: struts-blank contains a Message Resource file called application.properties. It's located in WEB-INF/classes/resources, but also in WEB-INF/src/java/resources. Since Eclipse knows that the Java source is placed in the WEB-INF/src directory and the classes in

WEB-INF/classes, it'll create a new classes folder called java/resources. As a consequence we now have application.properties in three places:

What a mess. But the cure is simple: right-click the project, select "Properties" and change the project's source folder from WEB-INF/src to WEB-INF/src/java:

You do this be selecting "StrutsBlank/WEB-INF/src", then click "Edit..." and then select the java folder. Then "OK" twice. As a consequence you'll have to place the source for new Java classes in the java folder.

Try the struts-blank application, but first reload Tomcat (so it'll recognize the new Eclipse project) and then enter this URL in the browser:

http://localhost:8080/StrutsBlank

The browser will then show this page:

From the URL field you can see that Struts has processed the Welcome action.

A more complex Struts application

In order to be able to develop a Struts application we need to go one step further. This is evident if we, for example, import the struts-validator war-file in a new Tomcat project. Several of the class files will be flagged with errors:

   

These errors will disappear when we add the Struts jar-files to the classpath. Right click the project, select Properties, Java Build Path, Libraries. Click the "Add JARs..." button and add all the jar files from the lib directory:

Press "OK" and the flags will disappear. Again, try the Validator after having reloaded Tomcat, by using this address:

http://localhost:8080/StrutsValidation

On the page that is shown, you may try several of the Validator features available in Struts.

Since this project is more "real-life" than the other ones we have used in the article, you might want to see the debugging features in a more realistic environment. Try for example to set a breakpoint in the Action class MultiRegistrationAction:

In the browser select the link "Multi-page Registration Form", and fill in some values in the HTML form, and press Save. The Eclipse debugger is now active, and the Action class's variables may be inspected--and changed-- for example the form fields:

If you change something in the MultiRegistrationAction class and save it, you'll see Tomcat re-loading several files, for example the Validator's XML-files. Not every changed file will force a reload, however. If you change struts- config, you'll have to reload it manually, as described above.

 

Conclusion

When considered separately Eclipse, Tomcat, and Struts are all great software products. Used together their value is further increased to give you a very solid development environment, with a lot of the features that you need and should expect from development tools of today. If you further add a few other tools like Log4J (for logging), JUnit and StrutsTestCase for unit test, and also implement some solid error handling, you really have what's needed to work productively.

But you'll have to try it out for yourself, and my advice is to use the time needed to get to know the tools. Eclipse has a lot of very useful features, like code-completion, refactoring and source formatting. Read the help files and try the features out.

When we look at Struts, then its full potential only becomes apparent when you work with it. My advice is to read articles on the web or buy one of the good books on Struts. See the resources section for hints.

Happy coding! 

Resources

The home of Eclipse: www.eclipse.org The home of Tomcat: jakarta.apache.org/tomcat

The home of Struts: jakarta.apache.org/struts

The Sysdeo Tomcat plug-in: www.sysdeo.com/eclipse/tomcatPlugin.html

Previous articles from JavaBoutique about Struts:- " Stepping through Jakarta Struts"- " Coding your second Jakarta Struts Application"- " Introducing: the Struts bean and logic Tag Libraries"- " Stepping through the Struts 1.1 Validator"- " StrutsTestCase: The Tool for Struts Unit testing"

One of the best books about Struts is " Programming Jakarta Struts" by Chuck Cavaness.

Keld is currently working as a web architect for one of the largest IT companies in Denmark. He battled with the mainframes during the 70's when they were the size of a gymnasium and had the power of your PalmPilot. He also struggled with CASE-tools in the 90s and now explores the cutting edge technology of the Web. While not busy at his computer he likes to vacation on the Greek islands.