Using and Writing Java Servlets
Point your web browser to http://localhost.localdomain/examples/servlets/, and execute any one of the examples to confirm that your installation and environment is a success. Another way is to use http://localhost:8080/.
If you do experience problems, you will need to revisit the setup documentation. Unfortunately, the documentation is not very user-friendly for any of the servlet enablers I use. You also can read the various FAQs and forums available on the Apache web site and servlet enablers.
Listing 1 is an example of creating a servlet. This example will generate a web page that will display a simple message.
Note that a servlet extends the HttpServlet class. This is located in the Tomcat installation directory, in this instance /var/tomcat/lib/servlet.jar. When you want to generate HTML output, it is necessary to obtain the output channel with response.getWriter(). It also is necessary to set the CLASSPATH to include the full names of the .jar files, e.g.,
Next, compile with javac FirstServlet.java. Ensure that you are using the same JDK that Tomcat has been set up to use (as described previously).
To make things simpler for the this exercise, place the generated .class files into /var/tomcat/webapps/examples/servlets (the actual configuration of Apache and Tomcat are beyond the scope of this article). To execute the servlet, open the web page at http://localhost.localdomain/examples/servlet/FirstServlet or http://localhost:8080/servlet/FirstServlet. And viola, the output seen below has been created dynamically:
Hello Fellow Servlets
Listing 2 not only demonstrates how to display useful information, but also shows the security concerns involved. Servlets must be written so that no input from a remote browser can give a cracker access to certain resources. Even something simple, like causing an error in the servlet, may cause the JVM to perform differently.
The example generates the HTML code for a table, which a selective query populates by the output provided from a system API to retrieve certain configuration variable settings (see Listing 3). This, for instance, can be used as a template to a database query using JDBC (Java Database Connectivity).
Listing 4 demonstrates how a servlet can not only generate dynamic web pages, but also process incoming data via an HTML form. To process input from a form, it is necessary for the servlet to override two functions: doGet and doPost. The doGet function always needs to be defined and forms the default behavior of the servlet and the processing of HTML form data sent via the GET method. The doPost function is used only when HTML form data is sent using the POST method, which is a more robust way than the GET method. In this example, doGet reports an error because it will be invoked only if the HTML form data was not sent with the POST method. In the doPost function, the request.getParameter calls are used to retrieve the corresponding parameter's value. Those of you who have used other CGI scripts may notice that this is a very simple and straightforward way to retrieve these values, which usually can end up being an onerous task.
Listing 5 shows the HTML input form, which a servlet could also have generated. Figure 1 shows a snapshot of this form.
The output reorganizes the entered data and displays it as an HTML page:
Hello, your name is Polly, Molly Polly
Again, this data could have been passed to a file or database.
- Geek Guide: The DevOps Toolbox
- Nmap—Not Just for Evil!
- Download "The DevOps Toolbox: Tools and Technologies for Scale and Reliability"
- High-Availability Storage with HA-LVM
- Resurrecting the Armadillo
- DNSMasq, the Pint-Sized Super Dæmon!
- Real-Time Rogue Wireless Access Point Detection with the Raspberry Pi
- March 2015 Issue of Linux Journal: System Administration
- Localhost DNS Cache
- Days Between Dates: the Counting