Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 104 105 106 107 108 109 < 110 > 111 112 113 114 115 116 .. 166 >> Next

However, this still does not explain why seven slashes works—in fact, any multiple of slashes other than two works. It appears that this is merely because the code checks for two slashes to be a remote host and resolves any number of slashes other than that to a path. This clearly does not strictly adhere to RFC2396, but this is not something developers frequently know or even care about until running across this problem.
Item 35: Reading Files from Servlets
When developers begin to write servlet code, they quickly come across one major reality: They are writing code that runs within the context of another application (a servlet engine). Since they are within the context of another application, they are forced to live within that context, or at least they should be. Unfortunately, this is not always the case. One major advantage of servlets is their access to the entire Java programming language, but it means that servlets can be written to do a number of ill-advised things within the servlet engine. This includes reading files from the local filesystem.
Listing 35.1 is an example of the problem. For the sake of simplicity, ignore the practice of hard-coding "header.html" into the example.
Reading Files from Servlets 303
01 public class ReallyBadReadingServlet extends HttpServlet {
02 private static final String CONTENT_TYPE = "text/html";
03 private StringBuffer strBuf;
04 private String header;
05
06 /**Initialize global variables*/
07 public void init(ServletConfig config) throws ServletException {
08 super.init(config);
09
10 strBuf = new StringBuffer();
11 try {
12
13 BufferedReader bufRead = new BufferedReader(new ^
FileReader("header.html"));
14
15 while (bufRead.read() != -1){
16 strBuf.append(bufRead.readLine());
17 }
18
19 bufRead.close();
20
21 } catch (IOException ioe) {
22 ioe.printStackTrace();
23 };
24
25 header = strBuf.toString();
27 }
28
Listing 35.1 ReallyBadReadingServlet.java
The example shows a conventional BufferedReader buffering a FileReader. The servlet is reading a header file to include with output. This is a simplified example of reading and processing a file.
The major problem with this code is that the working directory, where it will seek the "header.html" file, cannot be reliably determined between servlet engine implementations. As an example, some vendors run their servlet engine in the same process as their HTTP daemon (to improve performance). In an effort to keep the implementation simple, a frustrating search for where to place the file begins, which ends up costing the developer a lot more time over a small subtlety in the servlet specification. It bites the developer again if he or she deploys the servlet into another servlet engine.
304 Item 35
The servlet specification does have a couple of methods that can help avoid this problem. First, every servlet has a ServletContext object, which has a getReal-Path(String virtualPath) method. This means that it will give the local filesystem path for the specified virtual path. Notice in the example in Listing 35.2 that localPath is prepended to the "header.html" filename.
01 public class StillBadReadingServlet extends HttpServlet {
02 private static final String CONTENT_TYPE = "text/html";
03 private StringBuffer strBuf;
04 private String header;
05
06 /**Initialize*/
07 public void init(ServletConfig config) throws ServletException {
08 super.init(config);
09
10 ServletContext context = config.getServletContext();
11
12 String localPath = context.getRealPath("/myapp");
13
14 strBuf = new StringBuffer();
15 try {
16
17 BufferedReader bufRead = new BufferedReader(new FileReader(localPath 2
+ header.html"));
18
19 while (bufRead.read() != -1){
20 strBuf.append(bufRead.readLine());
21 }
22
23 bufRead.close();
24
25 } catch (IOException ioe) {
26 ioe.printStackTrace();
27 };
28
29 header = strBuf.toString();
30
31 }
32
Listing 35.2 StillBadReadingServlet.java
The problem with using getRealPath() occurs when the path you are attempting to get is within a Web Application Archive, also known as a WAR. The getRealPath() method will return null as its result. A WAR can be thought of as the Web equivalent of
Reading Files from Servlets 305
a JAR file. It provides a deployable component to plug into a Web server, which contains all of the servlets, filters, JSPs, tag libraries, HTML pages, and images.
In the situation shown in Listing 35.3, the developer specifies an explicit path for the file in the local filesystem (e.g., C:\pitfallsbook\code\header.html). This definition is specified within parameters passed to the ServletConfig object, but the concept can be implemented in a number of ways. No longer using an implicit path definition, the developer decides to place the burden of the deployer to specify a path that is valid (and accessible). So, while this solves the first problem of not definitively knowing where files should be stored, it still doesn't help if we are using the WAR (as is a good practice).
Previous << 1 .. 104 105 106 107 108 109 < 110 > 111 112 113 114 115 116 .. 166 >> Next