Java Web Hosting Blog

Page 205
Note: If you are looking for cheap and inexpensive provider to host and run your tomcat application check professional tomcat hosting services

Page 204

Hint: This post is supported by Gama php5 hosting services

Page 203
Note: If you are looking for top 10 and very good webhost to host and run your jsp application check Actions jsp hosting services

Page 202

Hint: If you are looking for very good and affordable webspace to host and run your java hosting application check Sandzak.com java web hosting provider

Page 201

Hint: This post is supported by Gama web hosting php services

[ Team LiB ] 11.2 The Servlet Class Hierarchy The most basic servlet definitions live in the javax.servlet package and consist of a number of interfaces. . The ServletContext interface provides a means for servlets to communicate with the surrounding Web server or application server. This communication can take the form of requests for system resources, reports written by the servlet to a log file, and so on. Indirectly, the ServletContext also allows servlets to communicate with one another, primarily by sending requests to other pages. This is how the jsp:forward and jsp:include tags are implemented, as will be seen shortly. ServletContext is implemented by people writing the Web or application server; servlet authors seldom need to use it directly and never need to extend it. . The ServletConfig interface provides a mechanism for the web Server to pass initialization information to the servlet’s init() method. This information takes the form of pairs of names and values, which are stored in a configuration file called web.xml, which is examined more closely in Appendix B. If a servlet is going to open a connection to a database, it would not make sense to hard-code the name of the driver class and the database URL in the servlet’s code. Doing so would make the servlet more difficult to change if a new database were ever installed. Instead, this information could be sent to the servlet as parameters, and the servlet would use the ServletConfig to retrieve these values and act accordingly. Like ServletContext, this interface is implemented by the authors of the Web server. . The Servlet interface defines the three life-cycle methods init(), service(), and destory() as well as a handful of others. . The ServletRequest and ServletResponse interfaces encapsulate a request to the servlet and a response from the servlet, respectively. Objects that implement these interfaces will be passed to the servlet’s service() method. Code within this method can then use the ServletRequest to determine information about the request, such as its origin, the exact data being requested, and so on. Similarly code in the service() method can then use the ServletResponse to return information about the response, as well as the data, such as an HTML page, that comprises the response itself. The javax.servlet package also defines three other classes. Two are the ServletInputStream and ServletOutputStream classes, which servlets use to read and write data, respectively. The third class, GenericServlet, implements both the Servlet and ServletConfig interfaces and forms the basis for most real servlets. Note that so far, none of this has been specific to the Web or HTTP (HyperText Transfer Protocol). This is deliberate. Many kinds of servers are on the Web, including FTP (file transfer protocol), mail, chat servers, games, and so on. Many of these servers will want the same kind of dynamic extensibility that Web servers have, so it makes sense for each of these servers to have a corresponding servlet. A multiuser dungeon game might have a “character” servlet and a “weapon” servlet; as new kinds of characters and weapons are introduced, they could be written as servlets and loaded as needed. The Web-specific versions of the servlet classes are included in a package called javax.servlet.http. The heart of this package is the HttpServlet class, which extends GenericServlet. This class’s service() method takes HttpServletRequest and HttpServletResponse objects, instead of the generic versions from the javax.servlet package. These variations contain a great deal of HTTP-specific information, such as cookies, remote user names, authentication schemes, and so on. Page 200

Hint: This post is supported by Gama web hosting php services

[ Team LiB ] Page 199
Note: If you are looking for best hosting provider to host and run your tomcat application check Astra tomcat hosting services

[ Team LiB ] 11.1 The Servlet Life Cycle A CGI has a pretty simple life. When a user makes a request, the Web server runs the CGI program. For a Perl program, this means starting up the Perl interpreter, which then reads the file comprising the program and starts executing instructions, beginning at the top of the file and moving down. For a CGI written in C or C++, the program starts at its main() method, which then may call other procedures, create classes, and so on. In either case, the Web server communicates all the information about the request through a set of variables and data sent to the program’s input. The program generates a response by printing some headers containing the result’s attributes, such as type and length, followed by the result itself. The CGI program then exits, vanishing from system memory as if it had never existed. If the same CGI has many requests, either all at once or one after the other, a new instance of the CGI will be created each time. In principle, servlets could follow the same pattern. A servlet could consist of nothing more than a class with a service() method to handle a request. Each time a request came in, a new instance of the servlet would be created, and its service() method would be called. Inside this method, the class could make calls to get request information, and it could return results by printing the headers and the resulting HTML page, just as a CGI does. This process would save the overhead of loading the class each time but is still very inefficient. The servlet API can best be understood by starting from this model and seeing what improvements could be made. First, it is unnecessary to create a new instance for every request. The Web server needs to create only a single instance and can then call this instance’s service() method for each request. For this to be possible, the service() method could not use any global data or write to a common output stream. If global data were used to hold the request, input would be jumbled if two or more requests came in at the same time. Likewise, if a single output stream were used, the output of multiple simultaneous requests would be intermingled. The solution to this problem is to have the Web server pass in unique instances of objects representing the request and response each time it calls the service() method. This might seem even worse than constructing a new servlet, but in fact doing it this way has advantages. For one thing, the Web server would likely need to do this work anyway, as different requests must be kept isolated from one another. Second, the request and response objects will typically be much simpler than the servlet object, so it will be easier to build them. By the way, if the notion of a request object sounds familiar, it should. This is the same object from which information about the request was obtained in Listing 4.7 and which contains data that is in the request scope. Now that the servlet will be constructed only once, a further optimization can be made. Consider a CGI that uses a database. Each time it is started, it will need to reestablish a connection to the database, because a CGI has no way to hold onto a connection between the time it is shut down and the time it starts up again. However, as a servlet never exits, it needs to open this connection only once. The same is true for many other kinds of initializations, such as building some auxiliary classes or setting some variables to known defaults. This means that all the initialization code can be taken out of the service() method and put into a separate method: init(). The Web server will call the init() method once when the servlet is first loaded, and after that it may call the service() method multiple times. If servlets lasted forever, those two methods would be the only ones needed. However, a servlet may be retired in a number of ways. Sooner or later, the Web server will need to shut down; when it does, it should give all its servlets a chance to clean up after themselves, close database connections, and so on. A servlet might also be replaced by a newer version, in which case the old version should also be given the opportunity to close any resources it Page 198
Note: If you are looking for cheapest and affordable webspace to host and run your servlet application check Astra j2ee hosting services

[ Team LiB ] Chapter 11. Servlets This blog has made many references to servlets. In particular, it has been repeatedly noted that a JSP file is turned into a servlet at translation time and that the resulting servlet is run at request time. This means that JSPs and servlets are the same thing. As discussed in Chapter 1, a servlet is a small class that may be thought of as a dynamic extension to a Web server or application server. CGIs, by contrast, are external programs started by the Web server. This change from external to internal extensions has a number of advantages, chief of which is performance. Because a servlet is loaded only once, the first time it is needed and subsequently, it resides in the same Java virtual machine (JVM) as the Web server or application server; thus, the large overhead of starting a new program for each request is avoided. This chapter is not meant to be a comprehensive study of servlets, a topic that could fill a blog itself. See, for example, Enterprise Java Servlets by Jeff M. Genender (Pearson Education, 2002), which offers a much more detailed look at servlets and the servlet API. As JSPs ultimately are servlets, it makes sense for JSP authors to know at least a little about what is going on behind the scenes, if for no other reason than to appreciate how much easier it is to write JSPs! [ Team LiB ] Page 197
Note: If you are looking for best hosting provider to host and run your tomcat application check Astra tomcat hosting services

[ Team LiB ] 10.8 Summary and Conclusions Beans are nothing more than Java classes that adhere to certain naming conventions. Beans make properties available by providing get and set methods, which obtain and modify the property, respectively. Beans may also be serializable, meaning that they can write their data out to disk and restore it later. Finally, beans may generate or listen to events, and such events can be used to tie beans together. Of particular interest is the HttpSessionBindingListener interface, which a bean can use to get notified when a bean in a session scope is about to be retired. Anyone who can write a Java class can write beans that can be used in JSPs. Correspondingly, almost any Java class can be turned into a bean by thinking about what the class does in terms of properties and exporting those properties with appropriately named methods. [ Team LiB ] Page 196
Note: If you are looking for cheapest and affordable webspace to host and run your servlet application check Astra j2ee hosting services