” + branchAddress); // Append the closing tags of the HTML page caw.write(“”); // Re-calculate and set the new length of the writer’s buffer res.setContentLength(caw.toString().length()); // send the output to the Web browser out.write(caw.toString()); out.close(); } }

Following is the code of the response wrapper that has been used in the FooterFilter. This class overrides the method getWriter() to substitute the standard output stream with the customized one which is constructed in the filter. public class TextResponseWrapper extends HttpServletResponseWrapper { private java.io.CharArrayWriter buffer; public String toString() { return buffer.toString(); } public TextResponseWrapper(HttpServletResponse res){ super(res); buffer = new java.io.CharArrayWriter(); } public PrintWriter getWriter(){ return new PrintWriter(buffer); } }

We’ve mentioned various configuration parameters that can be used when a servlet is deployed. In the next section we’ll discuss in detail the process of servlet deployment and various parameters that can be used in the servlet’s deployment descriptor file, web.xml.

Chapter 5 ✦ Studying Servlet Programming

Deploying servlets Java Community Process provides the following definition of a Web application in the servlet specification: “A Web application is a collection of servlets, HTML pages, classes and other resources that make up a complete application on a Web server.” J2EE defines a standard way to deploy Web applications. It suggests that all components of a Web application should be packaged in the Web application archive (WAR) — the file with extension .war, which has the same format as .jar files. (The WAR is discussed next.) A Web application could be deployed either independently in the .war file, or it could be included in the Enterprise Application archive (.ear file) along with other application components, such as Enterprise JavaBeans. (See Part IV, “The Service Tier” for details.) Multiple Web applications can be deployed on the same application server. Keep in mind though, that an application server assigns the same cookie name (JSESSIONID) for the session tracking cookies for all Web applications. If you use this name for the user authentication, refer to your vendor’s documentation to see how to control the name of the cookie in the Web application. For example, the WebLogic application server provides a special deployment parameter CookieName for this.

The Web-application archive Web-application archives are created with the Java jar utility, just like regular Java archives, which contain multiple files in a compressed form compatible with zip files. A sample jar command is shown at the end of this section. The WAR has to store deployed files using the following directory structure: ✦ The top level contains the resources that you’d put in a regular document root directory (HTML files, JavaServer Pages, and client-side resources). ✦ The META-INF subdirectory contains the file manifest.mf, which contains information about the files in this archive. ✦ The WEB-INF directory can contain the web.xml deployment descriptor and JSP tag library descriptors, if any. ✦ The XML web.xml file maps names of the deployed objects to full names of corresponding Java classes, and can contain some other application properties such as session configuration, security, and others. ✦ Subdirectory classes contain compiled servlets, beans, and utility classes. ✦ The lib subdirectory is for any additional jar files. If the same class exists in the subdirectory classes as well as in jar, the version from the classes directory is loaded. ✦ The tlds subdirectory is for JSP tag libraries (see Chapter 7, “Using JSP Tag Extensions”), if any.

103

104

Part II ✦ The Presentation Tier

A Web-application developer usually creates this directory structure on the local disk, and creates the WAR when the files are ready for deployment. The following command adds all the files from the current directory into the file MagPublisher.war: jar cvf MagPublisher.war *

As long as your files are located in the directory structure described above, your Web application could be deployed even without creation of the WAR, which is typical for the development stage of the application. As we’ve mentioned in the beginning of this chapter, static resources such as HTML files, images, jars and applets could be processed be the Web server alone, that’s why you may leave these resources outside of the WAR in the document root directory.

Examining the web.xml Deployment Descriptor The web.xml deployment descriptor is an XML file that can be prepared by any plain-text editor. The application-server vendor may provide a GUI tool for creation deployment descriptors. While web.xml is a required file for every Web application deployed in a J2EE compliant application server, vendors may also create additional deployment descriptor files. Please refer to your vendor’s documentation describing the servlet deployment procedure. The web.xml file should start with a DOCTYPE element pointing to the proper DTD file. For example, for the Servlet 2.3 Specification this element should look like this:

Mandatory servlet elements The following servlet names are mapped to actual servlet classes that might be located in packages: LoginServlet LoginServlet BadLoginServlet com.security.BadLoginServlet

Chapter 5 ✦ Studying Servlet Programming

Optional Servlet Elements

While tags such as and are required elements, the following list includes some of the optional XML tags: ✦ is a servlet-initialization parameter that can be accessed by means of ServletConfig.getInitParameter() — for example: CustRepFile c:\custrep.ser

✦ indicates a servlet that has to be loaded, and whose init() method has to be called on the Web-application startup. This tag may be empty or have an optional integer value that specifies the order in which the servlet must be loaded. ✦ specifies the timeout for users’ sessions. The following example specifies a 60-second timeout: 60

✦ specifies the mapping between the hard-coded in the servlet security role and a defined in the deployment descriptor, as shown here: DIRECT director

-->

Servlet listener elements If event listeners were created for this Web application, they should be listed in the web.xml. Here’s an example: com.magpub.listeners.ContextListener ...

105

106

Part II ✦ The Presentation Tier

Servlet filter elements To deploy filters, add the section to the web.xml file, and also map the filter to the servlet that will be using the filter. For example: LogFilter com.magpub.filters.LogFilter LogFilter LoginServlet

To apply a filter to selected servlets repeat the section for each servlet. If you’d like the filter to be used by all servlets of the Web application use the section instead of the , for example to apply the

filter for all Web application objects use the following element: /*

The next example ensures that the filter will work only with JavaServer Pages (see Chapter 6): /*.jsp

To create a filter chain provide multiple sections. The following example ensures that request data will be logged and encrypted before reaching the LoginServlet: LogFilter LoginServlet EncryptFilter LoginServlet

The new deployment element allows you to specify if the filter has to be applied, for example only when a control is redirected by a forward() or include() call of a request dispatcher. The following section ensures that the LogFilter will be invoked only when the request’s generated by the call to a method forward() in the servlet LoginServlet: LogFilter LoginServlet FORWARD

Chapter 5 ✦ Studying Servlet Programming

The next descriptor will apply the filter MyFilter only to requests that come directly from the client: MyFilter /* REQUEST

The next section will show that not only HTML clients, but also Java applets could work with servlets.

Applet-servlet communication Because HTML alone does not provide advanced GUI components, Java applets with AWT or Swing components can become handy. The main business processing should still be done by the servlets on the server side, but applets can take care of the presentation part. Let’s take a look at the following applet/servlet design considerations: Applets have to be downloaded to the client’s machine, so we still want to keep them lightweight (small in size). Applets should not connect directly to server databases — this will make them smaller, because they won’t contain JDBC drivers. In Internet applications applets do not access the user’s disk, and therefore they should be used primarily for data entry, validation, display, and simple calculations. Applets may not work properly if the user’s Web browser has an outdated JVM. While applets can connect to a remote computer using socket or RMI programming, there is an easier way — HTTP tunneling, which is a way of creating a sub-protocol for specific tasks on top of the existing protocol (HTTP). With the help of the HTTP protocol, applets can establish a communication channel with servlets and send and receive any text and binary objects using Java Serialization. An applet can collect the user’s input from the GUI components, package the data in a serializable object, and send the data to the servlet. To receive data from a servlet, the applet has to play the role of a Web browser. It has to understand the data it receives and populate the appropriate GUI components. For example, if an applet expects to receive the magazine data as two values — the title and the price — it needs to get a reference to the servlet’s input stream and read the received values, as shown here: URL servetlURL = new URL(“http://www.mymagpublisher.com/ShowMagazines”); URLConnection con = servletURL.openConnection(); InputStream in = con.getInputStream();

107

108

Part II ✦ The Presentation Tier

BufferedReader servletData = new BufferedReader(new DataInputStream(in)); String magTitle = servletData.readLine(); String magPrice = servletData.readLine(); txtTitle.setText(magTitle); // display the data in a AWT TextField txtPrice.setText(magPrice);

What if a magazine is represented not by two, but by 50 values? Instead of performing 50 reads over the network we should pre-populate an object on the client side and send it to the servlet in one shot. Let’s look at the applet/servlet communication using Java Serialization, which allows easy conversion of a Java object into a stream of bytes. Our applet is going to prepare the magazine-subscription order and send it over to a servlet, which will save the order in a database. We could implement this process by performing the following steps involved in applet/servlet object serialization: 1. Create a SubscriptionOrder class that implements the Serializable interface. 2. Using Java AWT or Swing components, create an applet to collect subscription info. Include a Send button to enable the user to submit the order to a servlet. 3. Create a database table for storing the orders, and a servlet that can work with the database using JDBC. 4. In the applet, under the actionPerformed() of the Send button do the following: a. Create an instance of SubscriptionOrder and initialize it with the values entered on the screen. b. Connect to a servlet using the URLConnection class. c. Obtain a reference to the OutputStream object of the servlet. d. Create an instance of ObjectOutputStream, chaining it with the servlet’s OutputStream. Send the order to this stream using the writeObject() object. e. Close the streams. 5. In the servlet, do the following: a. Obtain a reference to the applet’s InputStream using request. getInputStream(). b. Create an instance of the ObjectInputStream, chaining it with the applet’s InputStream, and call the readObject() method to de-serialize the SubscriptionOrder instance. c. Connect to the database and save the order in the database. d. Close the streams.

Chapter 5 ✦ Studying Servlet Programming

Listings 5-5, 5-6, and 5-7 illustrate this process:

Listing 5-5: Code fragment from SubscriptionOrder.java class SubscriptionOrder implements java.io.Serializable{ private String magazineID; private int quantity; private String promoCode; private String custID; SubscriptionOrder(String magazineID, int quantity, String promoCode, String custID){ this. magazineID = magazineID; this.quantity=quantity; this.type=promocode; this.custID=custID; } public String getMagID (){return magazineID;} public int getQuantity(){return quantity;} ...

Listing 5-6: Code fragment from Client.java class Client extends java.applet.Applet implements ActionListener { ObjectOutputStream out = null; // The GUI components should be created here ... // The user pressed a button public void actionPerformed (ActionEvent event){ if (event.getSource() == buttonSend){ SubscriptionOrder sOrd = new SubscriptionOrder( listMagId.getSelectedItem(), Integer.parseInt(txtQuantity.getText()), txtPromo.getText(), txtCustID.getText()); try{ URL orderServlet = new URL(“http://www.mymagpublisher.com/ShowMagazines/OrderServlet” ); Continued

109

110

Part II ✦ The Presentation Tier

Listing 5-6 (continued) URLConnection con = orderServlet.openConnection(); //We are only sending data ,otherwise call also the setDoInput(true) con.setDoOutput(true); // We are sending the binary object, that’s why the content type // should be application/octet-stream. con.setRequestProperty (“Content-Type”, “application/octetstream”); out = new ObjectOutputStream(con.getOutputStream()); // Send the order to the servlet out.writeObject(sOrd); } catch(){ ... } finally{ out.flush(); out.close(); } } }

Listing 5-7: Code fragment from OrderServlet.java class OrderServlet extends HttpServlet{ // Since we are passing the binary data from the applet, // we can’t use doGet() public void doPost(HttpServletRequest request, HttpServletResponse response){ ObjectInputStream appletStream = null; SubscriptionOrder receivedOrder = null; try{ // get the applet’s input stream appletStream = new ObjectInputStream(request.getInputStream()); //de-serialize the order received from the applet receivedOrder = (SubscriptionOrder)

Chapter 5 ✦ Studying Servlet Programming

appletStream.readObject(); // connect do the database and save the received order // If the servlet needs to send some data to the // applet, it need s to call create an instance of // the ObjectOutputStream by using // request.getOutputStream(), and send a serializable // object over there. } catch(Exception e){ e.printStackTrace(); } finally{ ... appletStream.close(); } } }

A similar technique can be implemented to send data from a servlet back to the applet. For example, a servlet connects to the database, selects all orders of a given customer, puts the result set into a Vector, and serializes the result set into the applet’s steam. The applet de-serializes the Vector and populates a JTable. Examples of working with relational databases using JDBC can be found in the Chapter 18. The next section briefly lists some of the important new features of servlets that were introduced in the specification 2.4.

What’s New in the Servlet 2.4 Specification The Java Servlet Specification 2.4 is not a major upgrade of the servlet API, but some of the new features and changes are listed here: ✦ The ability to extend deployment descriptors will enable developers to insert application-specific configuration information into the deployment descriptor. ✦ New listeners will allow developers to use a ServletRequestListener instance to intercept events when a request comes in and out of scope (enters and exits the first filter in the filter chain). A ServletRequestAttributeListener instance will catch the events when attributes are being added to, removed from, or replaced on a ServletRequest instance. ✦ Filters can be configured and invoked under RequestDispatcher forward() and include() calls. ✦ Unhandled listener exceptions are propagated to the application’s code.

111

112

Part II ✦ The Presentation Tier

Summary In this chapter, we’ve introduced you to Java servlets that are widely used to create Web applications. While processing HTTP requests, servlet containers provide a concurrent multithreaded environment to improve the performance of such applications. Session management is yet another vital aspect of most of the Web applications, and you’ve learned various ways of storing session information.

✦

✦

✦

6

C H A P T E R

Going Over JSP Basics

✦

✦

✦

✦

In This Chapter

J

avaServer Pages (JSP) is a J2EE component that enables you to develop Web applications that work as if they had been created with Java servlets. The JSP specification defines JSP as “a technology for building the applications for generating dynamic Web content such as HTML, DHTML, SHTML, and XML.” This chapter will teach you about the various JSP scripting elements and directives. You will also learn how to work with variable scopes and experiment with a few examples. Finally, you will design an online store and then apply JSP to the Airline Reservation business case. Let’s begin with some simple examples.

Introducing JSP The first very basic examples discussed in this section will show the easy way of generating HTML content using JSP. Let’s say you’ve created and deployed a servlet that displays the HelloWorld HTML page by using println() in its doGet() method. Here’s that code: out.println(“”); out.println(“Hello World”); out.println(“”);

What if you need to change the layout of this page — say you want to add a header and a footer? Because you’ve already learned about Java servlets, you can easily add several out.println() statements, and then recompile the servlet and deploy it again. A real Web application can generate dozens of Web pages and each of them may need to be modified. Fortunately, JSP enables you to separate screen design from business logic, so a Web designer can take care of the HTML part while the Java developer concentrates on the programming of business functions required by the application.

Introducing JavaServer Pages Applying the model-view-controller design pattern Using JavaBeans with JSP Developing a sample user-login application Developing a sample user-registration application

✦

✦

✦

✦

114

Part II ✦ The Presentation Tier

Now, to see how a simple HTML page could be converted into a JSP, type into any plain editor the HTML code shown in Listing 6-1, and save it in a file named HelloWorld.jsp.

Listing 6-1: HelloWorld.jsp Hello World

This file has to be placed into a document root directory on the application-server machine or deployed in the Web application-archive file (as explained in the previous chapter). Now users can access this JSP from the Web browser by entering a URL like this: http://www.mydomainname.com/HelloWorld.jsp. Upon the first request to this page, the JSP container will automatically generate, compile, and deploy a servlet that produces the output based on the content of the file HelloWorld.jsp. The container will automatically generate the jspService() method in the new servlet, which will have the same functionality and arguments as the servlet’s service() method. The first request of the JSP will take longer than all single subsequent ones because of this generation process, but then the servlet will be up and running and will respond immediately. It does not take a rocket scientist to understand that we could have achieved the same effect by creating a HelloWorld.html file without all these complications. This is true, as long as your page is a static one and does not need to perform any business processing. Note

Remember, HTML is not a programming language, just a markup language. It could not perform even such a simple calculation as 2 + 2, but JSP can easily do it by using special tags that enable the programmer to embed Java code into an HTML page. During the servlet-generation process this Java code will also be included and executed as part of the servlet.

JSP elements are surrounded by angle brackets, like this: <%=2+2%>. The JSP container will replace these elements with the regular Java code. For example, the tag <%=2+2%> will be replaced with a Java statement similar to the following one: out.println(2+2);

Listing 6-2 shows the code for the MyFirstJSPPage.jsp file.

Chapter 6 ✦ Going Over JSP Basics

Listing 6-2: My First JSP You may not know that 2 + 2 is <%= 2 + 2%>

The code within the JSP tag was created by a Java developer, while the rest of the page has been done by the HTML person.

When this JSP is requested by the user, it will display the following text in the Web browser: You may not know that 2 + 2 is 4 The code within the JSP tag was created by a Java developer, while the rest of the page has been done by the HTML person.

Please note that the expression <%2 + 2%> has been replaced by the value of 4. A JSP tag <%= ... %> from the preceding example can contain any Java expression that will be evaluated, and its result will be displayed in place of the expression by the JSP engine. A JavaServer Page is nothing but a servlet that is automatically generated by a JSP container from a file containing valid HTML and JSP tags. The latest JSP specification is 2.0.The original Java Specification Request (JSR152) listed the version as 1.3. However, based on the scope of changes — such as introduction of the new Expression Language, the Standard Tags Library (JSTL), and some others — this specification has been released as version 2.0. The following sections explain the various elements of JavaServer Pages, starting with a discussion of the design of the Web applications, and specifically, applying the model-view-controller to the JSP technology.

Examining MVC and JSP The model-view-controller paradigm was briefly discussed in Chapter 1. Now, we will show you how to apply it in practice for Web applications. MVC suggests dividing the components of an application (or even an object!) into the three parts:

115

116

Part II ✦ The Presentation Tier

✦ The model — This component represents the application data and the business processing code. ✦ The view — This component is responsible for the presentation layer — Web pages or GUI screens, for example. ✦ The controller — This component provides a reaction to the user’s input, “input” being such things as button clicks. Even some of the Java Swing components were designed using the MVC pattern. For example, a JTable (the view) that looks like a spreadsheet can store its data in a different class, such as a descendent of the AbstractTableModel class (the model). For Web applications the MVC pattern can work as follows: The view portion is implemented by means of JSP, HTML, and JavaScript. The model portion of an application can be developed with any Java (and non-Java) classes such as beans, EJB, and JMS. It can also provide data storage using a database-management system, flat files, and so on. The controller is a navigation object that redirects control to appropriate classes based on the user’s choices or some other events that may happen in the system. For example, the user makes a selection on a Web page that has to be processed by a Java class or JSP. A Java servlet is a good candidate for this role. Any changes in page appearance (such as colors, fonts, or screen-real-estate allocation) can be made by the HTML person responsible for the presentation of the application. After the changes are applied and the modified JSP is deployed, the JSP will automatically be regenerated into a new servlet upon the first user’s request. (See an example in the section “Deploying Login JSP Example Using Apache Tomcat,” later in this chapter.) Since the business logic has not been changed (2 + 2 is still equal to 4), there is no need to change the model. See the section “Designing an Online Store with JSP,” later in this chapter, for a practical example of using the MVC paradigm. The next section will introduce you to the basic JSP elements that control the servlet generation process and allow embedding of Java code into HTML pages.

JSP Scripting Elements and Directives JSP elements (tags) can by grouped according to the functions they perform. For example, they can be referred to as variable declarations, expressions, page attributes, and so on. The tags are surrounded by angle brackets (<>), and like HTML and XML tags can have attributes. Everything else that can be contained in

Chapter 6 ✦ Going Over JSP Basics

the JSP page but that cannot be known to the JSP translators (plain text, HTML tags, and so on) is called template data. First we’ll discuss the use of the following tags and other JSP elements: ✦ Declarations ✦ Expressions ✦ Directives ✦ Scriptlets ✦ Comments ✦ Actions ✦ Implicit JSP objects ✦ Error pages ✦ JavaBeans Then we’ll build the Login and Registration screens for the Connexia Airlines business case described in Appendix A.

Declarations Declarations do not generate the output to the user’s screen. They are used for declaring class variables and methods and start with <%! . The lastName variable declared in the following code is only available in the current page: <%! String lastName; %> If you need to declare a Java method called myMethod() JSP you could do it as follows: <%! private void myMethod(){ ... } %>

in a

The code contained in the JSP declaration block will be located in the generated servlet outside any existing method.

Expressions JSP expressions start with <%= and can contain any Java expression, which will be evaluated and its result inserted into the HTML page right where the expression is located. For example: <%! double salary=50000; %> Your new salary is <%= salary*1.2 %>

117

118

Part II ✦ The Presentation Tier

The next example shows how to display the current date on the Web page: Today’s date is <%= new java.util.Date() %>

Please note that there is no semicolon (;) at the end of the expression.

Directives Directives do not generate screen output. They inform the JSP engine about the rules to be applied to the JSP. The page directive starts with <%@ page and will be applied during the servlet-generation process only to the current page. It’s used with such attributes as import, extends, session, errorPage, and contentType. For example, an equivalent of the Java import statement looks like this: <%@ page import=”java.io.*” %>

With servlets you set the type of the output by code like response. setContentType(“text/html”). The JSP version of this code is shown here: <%@ page contentType=”text/html” %>

Now consider the following example: <%@ page session=”true” %>

You can see that, as in servlets, the JSP containing this directive will try to find an existing session object, and if it does not find one will create a new one. You can find another example of the page directive in the section “Error Pages,” later in this chapter. The include directive allows inclusion of any text file or code from another JSP, at the time when the page is compiled into a servlet. For example, if every JSP in your application has to display the same header, you can place the code for the header in the file TheHeader.jsp and include it in every page. The following code fragment uses an HTML table to display a Web page with the content of the file TheHeader. jsp on top:

<% } %>

This mix will be converted into the Java code in the servlet, which may look like the following: if (userID.equals(“jSmith”)) { out.println(“Hello John! You’ve got mail.”); } else{ out.println(“Please register or login.

”); }

Even though the JSP syntax enables insertion of Java code fragments, variables, and method declarations, you should try to minimize the amount of Java code in the JSP body. Remember that the whole point of using JSP is to separate business processing from the presentation. That’s why the best practice is either to move Java code into JavaBeans, as shown later in this chapter, or to use custom tag libraries, as shown in the next chapter.

Comments JSP comments start with <%-- and end with --%>, and are not included in the output Web page: <%-- Some comments --%>

If you need to include comments in the source of the output page, use the HTML comments, which start with .

119

120

Part II ✦ The Presentation Tier

Actions JSP actions provide runtime instructions to the JSP containers. For example, a JSP action can include a file, forward a request to another page, or create an instance of a JavaBean.

JavaBeans and the use of the action will be discussed later in this chapter in the section, “Using JavaBeans.” I will briefly discuss the rest of the standard JSP action tags in this section.

forward The forward action enables you to redirect the program flow to a different HTML file, JSP, or servlet while maintaining the same request and response objects. This directive works in the same way as the forward() method of the RequestDispatcher class, described in the previous chapter.

include versus jsp:include Please note the following difference: the include directive adds the content of the included page at the time of compilation, while the jsp:include action does it at runtime. This adds flexibility to JSP, because the decision about what page to include can be made based on the user’s actions or other events that may take place when the Web application is already running.

plugin The plugin action ensures that if your JSP includes an applet, the Java plugin will be downloaded to the user’s browser JVM to avoid version-compatibility problems. During code generation, the tag will be replaced in the output stream by either an