As one can see from the code, the servlet first tries to create an Http session by calling request.getSession(true), which means that a new session will be created if one doesn't exist already, then we'll get the "sessiontest.counter" attribute from the session, which will be assigned 0 if it's null, increment it, and set it back to the session. The session will be invalidated (all attributes removed from it) when counter goes above five. We'll get an HTTP request header called "Cookie" and a reference to the HTTP response writer and pass them to the SampleProgram class (see Listing 8) that will perform the logic described below.

Creating a Test Class and JUnit Test Case
For our servlet to work, we'll create one more supporting class SampleProgram with a main method that can test all these supporting classes and will be eventually called by the servlet too.

As you can see, the program in Listing 8 uses all our classes. It can also be tested from the command line (without having to deploy a servlet in Tomcat) by creating a JUnit test case.

To create a JUnit test case in Eclipse, right-click on the class SampleProgram and select the menus New, Other, Junit, and Junit Test Case. It'll add the junit.jar to the classpath, if needed, and a window pops up asking how we want to create our test case.

Select setUp() and tearDown() methods to set up the test environment and tear it down when finished. Also select create main method and allow Swing UI so we can run our test visually. On the next screen select methods to test: main and testClasses.

Once finished, a SampleProgramTest class is generated and we can test it by selecting Run As - JUnit test from the context menu. JUnit will test to see if any exceptions occur and display them as errors. It will also display failures if any of our assertion tests fail. Below is the source code of our sample JUnit test (see Listing 9).

In both test methods, we've added method calls with arguments to make sure there are no exceptions. We also do an assertion that will definitely fail to demonstrate the JUnit failure detection capability:

junit.framework.ComparisonFailure: expected:<1> but was:<2>
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)

Coding Web.xml Deployment Descriptor
Web applications require a Web.xml deployment descriptor (see Listing 10), which should be put under the WEB-INF directory.

In our deployment descriptor, we've included our SampleServlet and the index.html as a welcome page.

Deploying Servlet Using ANT
Eclipse 3.1 comes with built-in ANT support so you can execute XML-based scripts to deploy your application in a specific application server. In our case, we're deploying under Tomcat 5.0 server, which also has built-in support for Ant for the following tasks:

• Deploying WAR files
• Reloading WAR files
• Undeploying WAR files

It makes deploying, redeploying, or undeploying an application easier. With Eclipse support for Ant, it's easy to create build an XML file with Ant tasks in it using Ant executor.

To take advantage of this support, we have to add Eclipse to the external catalina-ant.jar (which is located under the $TOMCAT\server\lib directory and contains support for Tomcat Ant tasks) to the runtime class-path before running Ant tasks. Select the menus Run, External Tools, and External Tools and double-click on the Ant-build.

Running Ant tasks is simple in Eclipse. Just right-click on your build file (you have to create a build.xml file containing your Ant tasks as in Listing 11) and select Run As - Ant Build, then select tasks to create-a war file, and deploy the application.

As you can see from Listing 11, there are four major tasks in the build:

• Creating the WAR file
• Deploying the WAR file to Tomcat
• Reloading the application
• Undeploying the WAR file from Tomcat

The file also contains variables used by these tasks. The notable ones are:

• "build" - where to build a WAR file
• "path" - the context root of the Web application, in this case "myapp"
• "url" - the url of the Tomcat administrative application (which comes with Tomcat and provides an inter-face for deploying/undeploying applications)
• username - the user name for the Tomcat admin application (in our case it's "admin")
• password - the password for the Tomcat admin application (in our case it's "admin")

The file also contains various "taskdef" entries that point to the Java classes inside catalina-ant.jar that define the execution of the particular tasks.

Using the Eclipse interface (right-click on build.xml file and select Run As - Ant Build...), these tasks can be executed one at a time or all together. Note that "Deploying the WAR file to the Tomcat" task is dependent on "Creating WAR file" task, so execute the "create-war" task first, then "deploy" task.

It's time for us to start the Tomcat server and deploy our application. In Windows, simply go to Control Panel - Services and start the Apache Tomcat service. In Unix, you can execute the $TOMCAT\bin\startup.sh script.

Once it's deployed (the ANT deployment task has been completed), just point your browser at http://localhost:8080/myapp/SampleServlet/ and you should see the output as in Figure 1.

Conclusion
In this article, I've shown you some of the new J2SE 5.0 elements and covered the creation of a Web application using simple tools available in Eclipse 3.1 and Tomcat 5.0, such as Java wizards, JUnit, and Ant. There are more advanced tools that can streamline and automate this development. One such extension to Eclipse is called Web Tools Project WTP (www.eclipse.org/Webtools), which I'll cover in a future article.