Web Applications with Java/JSP
All the cool new programming languages, like Ruby, always have compilers/interpreters and tools for Linux, and the old UNIX standbys like Tcl/Tk are still around when you need them. Why, then, is Java not a ubiquitous player in the Linux arena?
Linux and Java really do have a lot to offer each other. Both are rock-solid and scalable server-class software systems, and most college and university graduates with software-related degrees are familiar with them, making for a powerful combination. In this article, I introduce you to Java Web applications through the Java Servlet Specification, the Java programming language itself and Java Server Pages. These three tools can help you get a Web application running in a lot less time than you think.
The Java Servlet Specification defines a Servlet Container, a Web application and the Servlet API, which is the glue that holds these pieces together.
A Servlet Container is analogous to a Web server, but it also knows how to deploy and manage Web applications, and so it often is known as an Application Server. The Servlet Container provides services that support the Servlet API, which is used by the Web application to interact with HTTP requests and responses.
A Java Web application is a self-contained collection of configuration files, static and dynamic resources, compiled classes and support libraries that are all treated as a cohesive unit by the Servlet Container. They are somewhat different from standard LAMP-style Web applications, which are more like collections of associated programs or scripts than formally defined, self-contained units. To demonstrate a Java Web application, I have developed a simple “timesheet” featuring some of the standard Java libraries that helped me write it.
Typically, a Web application is packaged in a WAR (Web ARchive) file, which is just a ZIP file with a special directory structure and configuration file layout. The directory structure of the Web application logically and physically separates these types of files. The WEB-INF directory contains all the configuration files, a lib directory contains all libraries (packaged in JAR, or Java ARchive files), and a classes directory contains the application's compiled code. Listing 1 shows the file layout of the Web application for reference.
Listing 1. Contents of timesheet.war
index.jsp tasks.jsp WEB-INF/web.xml WEB-INF/lib/jstl-impl-1.2.jar WEB-INF/lib/jstl-api-1.2.jar WEB-INF/classes/lj/timesheet/Task.class WEB-INF/classes/lj/timesheet/GetTasksServlet.class WEB-INF/classes/lj/timesheet/BaseServlet.class WEB-INF/classes/lj/timesheet/Client.class WEB-INF/classes/lj/timesheet/SaveTaskServlet.class WEB-INF/classes/ApplicationResources_en.properties WEB-INF/classes/ApplicationResources_de.properties WEB-INF/classes/ApplicationResources.properties WEB-INF/classes/ApplicationResources_es.properties WEB-INF/classes/ApplicationResources_fr.properties META-INF/context.xml META-INF/MANIFEST.MF
The WEB-INF directory also contains a special file, web.xml, which is known as the Web application's deployment descriptor. It defines all the behaviors of the Web application, including URI mappings, authentication and authorization. Let's look at the deployment descriptor for this Web application.
Listing 2. web.xml
<?xml version="1.0" encoding="ISO-8859-1" ?> <web-app xmlns="http://java.sun.com/xml/ns/javaee" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5"> <servlet> <servlet-name>get-tasks</servlet-name> <servlet-class>lj.timesheet.GetTasksServlet</servlet-class> </servlet> <servlet> <servlet-name>save-task</servlet-name> <servlet-class>lj.timesheet.SaveTaskServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>get-tasks</servlet-name> <url-pattern>/tasks</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>save-task</servlet-name> <url-pattern>/save-task</url-pattern> </servlet-mapping> <security-constraint> <web-resource-collection> <web-resource-name>Protected Pages</web-resource-name> <url-pattern>/tasks</url-pattern> <url-pattern>/save-task</url-pattern> </web-resource-collection> <auth-constraint> <role-name>*</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>Timesheets</realm-name> </login-config> <security-role> <description>Users of the timesheet application</description> <role-name>user</role-name> </security-role> </web-app>
You can see that each servlet is defined in a <servlet> element that defines the Java class that contains the code, as well as a name for the servlet (to be used later). After the servlets have been defined, they are then mapped (by name) to incoming URIs using <servlet-mapping> elements. This servlet mapping may seem tedious and verbose, but it can be very powerful for several reasons:
You can map one servlet to multiple URIs.
You can use wild-card mappings (/foo/bar/*).
You may not want to reveal any of the code's structure to remote visitors.
You may have servlets you don't want to map at all.
After the servlet mappings come container-managed authentication and authorization. The Servlet Specification requires that Servlet Containers provide mechanisms for authentication and authorization, and the configuration in the Web application is declarative: web.xml simply specifies what resources are protected and who is allowed to access them, using role-based authorization constraints. The setup is quite straightforward, and the Web application becomes simpler by not having to implement that capability inside the application. In this application, I've chosen to use HTTP BASIC authentication to simplify the application. DIGEST, FORM and (SSL) CLIENT-CERT are other options allowed by the Servlet Specification.
Web Development News
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- Concerning Containers' Connections: on Docker Networking
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- Three More Lessons
- diff -u: What's New in Kernel Development