jsp dateformat

Corrections for Murach’s Java Servlets and JSP (2nd Edition) These are the corrections for the significant errors in each printing of this book. In addition to the corrections listed here, you may find some trivial typos and formatting errors. All types of corrections will be made in the next printing of the book. How to tell which printing your book is in Below the copyright notation on the back of the title page, you’ll find a series of numbers like this: 10 9 8 7 6 5 4 3 2 1 The number on the right of this sequence tells which printing your book is. In this example, it’s the first printing, which came out in January 2008. Corrections to the first printing Text corrections Chapter 7, page 211 Under the heading “How to set a request attribute for a primitive type,” the second statement should use a wrapper class for the int value like this: request.setAttribute("id", new Integer(id)); Chapter 8, page 253 Under the heading “How to disable cookies for Mozilla Firefox 2.0,” step 2 should have you click on the Privacy tab (rather than the Security tab). Chapter 14, page 442 In the second paragraph, the last two sentences should be replaced with the following two paragraphs: Since type-1 and type-2 database drivers require installation on the client side, they aren’t ideal for allowing an application that’s running on the client to directly access a database that’s running on the server. As a result, you’ll typically want to use a type-3 or type-4 driver for this type of application. With a web application, of course, all of the data access code runs on the server side. As a result, you can use any type of driver to connect to the database. However, you’ll typically want to use a type-4 driver whenever one is available for the database that you’re using. Chapter 17, page 532 In the first sentence of the opening paragraph, authentication is not defined accurately. In the next printing, we’ll replace that opening paragraph with the following: Although you can restrict access to certain parts of a web application by writing custom servlets and JSPs to work directly with HTTP requests and responses, doing that can be time-consuming and error-prone. That’s why most modern servlet containers such as Tomcat provide a built-in way to restrict access to certain parts of a web application. This is known as container-managed security, or container-managed authentication. Chapter 23, page 673 If you add multiple items to the cart and attempt to update the quantity, it won’t work. To fix this problem, you can move the tags for the cart/displayCart action within the forEach loop: ${item.product.description} ${item.product.priceCurrencyFormat} ${item.totalCurrencyFormat} Solutions to potential problems with the sample code Since the publication of this book, a few potential problems with the sample code have been brought to our attention. Fortunately, the solutions to these problems are relatively easy to implement. In addition, these corrections provide interesting insights into real-world threading and security issues. Chapter 8 and beyond: A threading issue for the Cart and Music Store applications The business objects in the Cart application that’s presented in chapters 8, 10, 11, 12, and 19 contain code that calls the getCurrencyInstance method of the NumberFormat class to return a NumberFormat object. For example, the Product class contains this getPriceCurrencyFormat method: public String getPriceCurrencyFormat() { NumberFormat currency = NumberFormat.getCurrencyInstance(); return currency.format(price); } The problem here is that the NumberFormat class does not guarantee that the NumberFormat object that’s returned will be thread-safe. In other words, it may return the same instance of the NumberFormat object to multiple threads. As a result, it’s possible that multiple users of this application could try to access the same NumberFormat object at the same time, which could lead to unanticipated results. As you might expect, the business objects in the cart section of the Music Store application that’s presented in chapters 21-24 have the same problem. In addition, the business objects have a similar problem with the DateFormat object that’s returned by the getInvoiceDateDefaultFormat method of the Invoice class. One way to solve this problem is to clone the NumberFormat or DateFormat object before you call any of its methods. That way, you can be sure that each thread has its own instance of the object. To make that easier, you can add a utility class to the package that stores the business objects. For example, you can create a class like this one: package business; import java.text.*; public class ThreadSafeFormat { public static NumberFormat getCurrencyInstance() { NumberFormat currency = NumberFormat.getCurrencyInstance(); NumberFormat currencyClone = (NumberFormat) currency.clone(); return currencyClone; } public static DateFormat getDateInstance() { DateFormat date = DateFormat.getDateInstance(); DateFormat dateClone = (DateFormat) date.clone(); return dateClone; } } Then, you can edit the methods of your business objects so that they call methods from the ThreadSafeFormat class instead of the NumberFormat or DateFormat classes. For example, the Product class could contain this getPriceCurrencyFormat method: public String getPriceCurrencyFormat() { NumberFormat currency = ThreadSafeFormat.getCurrencyInstance(); return currency.format(price); } Another approach to solving this problem would be to use the synchronized keyword in the business classes to synchronize all calls to the NumberFormat and DateFormat objects, like this: public String getPriceCurrencyFormat() { NumberFormat currency = NumberFormat.getCurrencyInstance(); String formattedPrice; synchronized(currency) { formattedPrice = currency.format(price); } return formattedPrice; } However, this approach is more error-prone and more difficult to maintain since you need to add the same code in multiple places within the business classes. As a result, I recommend using a utility class like the ThreadSafeFormat class shown above. Chapter 18: A security issue for figure 18-11 In figure 18-11, the code in the doGet method of the DownloadFileServlet gives the user access to the entire web application. As a result, the user can download any file in the entire web application, including the source code for the application. For example, the user can download the web.xml file for the application with this request: http://localhost:8080/ch18http/downloadFile?name=WEB-INF/web.xml To fix this problem, you can create a subdirectory that stores the downloadable files. For example, I created this subdirectory: downloads Then, you can move any files that you want to allow to be downloaded into that subdirectory. For example, I moved the MP3 and PDF files into this directory. Finally, you can modify the code in the doGet method of the DownloadFileServlet, so it only allows access to this subdirectory. For example, I modified the code in the doGet method so it starts like this: ServletContext sc = getServletContext(); String path = sc.getRealPath("/downloads"); String name = request.getParameter("name"); response.setContentType("application/octet-stream"); response.setHeader("content-disposition", "attachment; filename=" + name); FileInputStream in = new FileInputStream(path + "/" + name); PrintWriter out = response.getWriter(); At this point, the code is secure. However, to get the sample application to work correctly, you still need to edit the two links in the index.html page that directly request the MP3 and PDF files. For example, you can request the MP3 file like this: Use an HTML link to download an MP3 file
If you want to take this one step further, you can prevent a user from directly requesting the downloadable file by storing it in a subdirectory of the WEB-INF directory such as this directory: WEB-INF/downloads Then, the user will only be able to access the downloadable file by using the DownloadFileServlet to request the file.