servlet : Java Glossary

Java Glossary : servlet

Java definitions: 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

an application designed to run on a server in the womb of a permanently resident CGI mother program written in Java that provides services for it, much the way an Applet runs in the womb of a Web browser. You can download the standard servlet extension API.

Servlet Advantages

Servlets have the following advantages over CGI.

A Servlet does not run as a separate process. This removes the overhead of creating a new process for each request.
A Servlet stays in memory between requests. A CGI program (and its runtime support) needs to be loaded and started for each CGI request.
There needs to be only one copy of the servlet in RAM at a time. Using threads, it can service several requests simultaneously. With CGI there is one copy of the code for each transaction in process.
The servlet sandbox can watch over the servlets to make sure they behave themselves. In traditional CGI programming, a coding error can bring down the entire system.

Servlet Extensions

There are various ways of writing server code that build on top of the basic Servlet classes. JSP and Freemarker let you embed bits of Java code, and other scripting inside your HTML pages. These are parsed and converted to Java Servlet programs that dynamically generate HTML with variable fields. These are automatically recompiled as needed.

With JSP all you have to do is drop the *.jsp files in a magic directory and away you go. With Servlets you must put the *.class files or *.war files in a magic directory, and register the servlets in a web.xml file that maps application name to servlet class among other things.

Writing Servlets in XML

In the following web.app example, the user types http://localhost:8080/hello. That is mapped to a servlet named hello-world. That servlet is implemented by the Java Servlet test.HelloWorld.class.

<web-app>
<servlet-mapping url-pattern='/hello' servlet-name='hello-world'/>
<servlet servlet-name='hello-world' servlet-class='test.HelloWorld'/>
<init-param greeting='Hello, world'/>
</web-app>

Under the Hood

javax.servlet.Filter is an interface to allow a transaction to be processed in an assembly line. Each Filter does some of the work and passes on the input or output to the next filter in the chain, and decides on who is next.

Getting Started

Getting your first HelloServletWorld working can be quite a challenge.

First you want to set up a dummy domain. Add the line:
127.0.0.1 practice.org
to your c:\winnt\system32\drivers\etc\hosts file.
If you are using Caucho Resin, add a line something like this to your resin.conf file to tell Caucho where your servlet and JSP code is.
<host id="practice.org" app-dir="c:/com/mindprod/practice" />
Set up C:\com\mindprod\practice\WEB-INF\lib with the usual servlet jars.
Put your *.jsp source code (which does not use packages) in c:\com\mindprod\practice.

view
Put your servlet *.java source code (which does use packages) in c:\com\mindprod\practice\WEB-INF\src\com\mindprod\practice.

view
After you shutdown and restart Caucho Resin, it will automatically recompile both files as needed.
To invoke a typical JSP, type http://practice.org:8080/HelloJspWorld.jsp?firstname=Roedy
To invoke a typical Servlet, type http://practice.org:8080/servlet/com.mindprod.practice.HelloServletWorld?firstname=Roedy

Debugging Tips

Sometimes the log output will appear in the WEB-INF\logs directory and other times in the \log directory of the servlet womb. Just look for fresh *.log files.
The most generic way to log debugging information is via:
```
this.getServletContext().log( "oops: database connection lost" );
```
System.out. println and System.err. println may or may not work in any given womb.
Put a version number that you increment with every compile on every screen and log output so you can be sure you are not getting on old version stuck in the browser's or womb's cache. So many times when you think something does not work it is because you are testing an old version. You can crank it back down to something less embarrassing after you get the code debugged.
Write a dummy doGet method that just echos the version number. You can then trigger recompilation from a browser, and you can easily tell if your Servlet is alive and which version it is running.
Write a dummy doGet method that throws an Exception which will cause the womb to shutdown and reinitialise the Servlet.
You don't need to calculate the Content-Length of the data you are returning. It will be calculated for you after you close the PrintWriter.
You will generate a -1 responseCode unless you use HttpServletResponse. setStatus ( HttpServletResponse. SC_OK );
Do a trim() on your getParameter because it includes the \r\n on the tail end of the last parameter.