www.codestyle.org

Java servlet API FAQ

This FAQ is part of the Code Style Help and FAQ section. Use the help request form below if your question is not answered here, but make sure you are asking the right question first.

Subscribe to this FAQ:

Servlet implementation

Q: What types of Servlet are there?

A: In the Java servlet API there are several sub-interfaces and implementations of the Servlet interface. The GenericServlet class has general purpose implementations of servlet methods that are common to all, including getInitParameter(String), init(ServletConfig) and log(String). GenericServlet is abstract and leaves the key method service(ServletRequest, ServletResponse) abstract for sub-class implementation.

More details available to subscribers:
What types of Servlet are there?

Q: What is the class structure of servlets?

A: The class structure of servlets is fundamentally the same as any other Java class, however they must fulfil the Servlet and GenericServlet interface. These interfaces define a set of so-called lifecycle methods, a service method and various supporting methods for getting servlet configuration parameters and for logging.

The lifecycle methods init(ServletConfig) and destroy() are called when the servlet container first puts the servlet into service and ultimately removes it. The basic service(ServletRequest, ServletResponse) method is called whenever a servlet request is received by the servlet container.

More details available to subscribers:
What is the class structure of servlets?

Q: Why is HttpServlet declared abstract?

A: The HttpServlet class is declared abstract because the default implementations of the main service methods do nothing and must be overridden. This is a convenience implementation of the Servlet interface, which means that developers do not need to implement all service methods. If your servlet is required to handle doGet() requests for example, there is no need to write a doPost() method too.

Q: What's the difference between GenericServlet and HttpServlet?

A: The GenericServlet is an abstract class that is extended by HttpServlet to provide HTTP protocol-specific methods. Java application developers normally extend the HttpServlet because it implements all the HTTP features necessary to create a Web application.

The GenericServlet does not include protocol-specific methods for handling request parameters, cookies, sessions and setting response headers. The HttpServlet subclass passes generic service method requests to the relevant doGet() or doPost method. In principle, the GenericServlet could be extended to implement other protocols, such as an FtpServlet for example.

API classes and methods

Q: Why are there separate ServletRequest and HttpServletRequest types?

A: ServletRequest and HttpServletRequest are interfaces, not a classes. Servlet containers must provide their own implementations of these types, which are passed to servlets' doGet and doPost methods.

More details available to subscribers:
Why are there separate ServletRequest and HttpServletRequest types?

Q: What's the difference between a servlet session and a servlet context?

A: A servlet session is a very different thing from a servlet context. An HttpSession is a mechanism used to simulate and maintain a continuous user session between a Web browser and Web application, largely managed by the servlet container. The HTTP protocol is stateless, it is essentially a request-response scheme, so servlet sessions are maintained by passing a unique HTTP cookie value for each request, or by dynamically including an identifier in servlet URLs, known as URL-rewriting.

A ServletContext object represents the overall configuration of the servlet container and has several methods to get configuration parameters, exchange data amongst servlets, forward requests and load resources. The servlet context is usually obtained indirectly through the ServletConfig object, passed to a servlet's init(ServletConfig) method, or from the servlet getServletConfig() method.

Q: What's the use of the servlet wrapper classes?

A: The HttpServletRequestWrapper and HttpServletResponseWrapper classes are designed to make it easy for developers to create custom implementations of the servlet request and response types. The classes are constructed with the standard HttpServletRequest and HttpServletResponse instances respectively and their default behaviour is to pass all method calls directly to the underlying objects.

More details available to subscribers:
What's the use of the servlet wrapper classes?

Handling requests

Q: I have overridden the service method, what next?

A: For most common servlet implementations you should not override the service method, only the doGet or doPost methods. The servlet container provides its own abstract implementation of the HttpServlet class and its service method forwards requests to the doGet or doPost methods as appropriate.

Q: HttpServletRequest is an interface, how do I get an instance?

A: The HttpServletRequest interface is implemented by the servlet container. The container instantiates and passes servlet request and response objects to the servlet's service method, which calls doGet or doPost in turn.

Q: Which is faster, doPost() or doGet()?

A: Neither doPost() or doGet() methods are intrinsically faster than each other. The speed with which a servlet container responds to such requests is partly a matter of how much data is submitted with the request and the statements your servlet methods contain.

HTTP post forms are often designed to submit longer free-form text content, but this is not necessarily the case. If any servlet request handler does a great deal of data retrieval, network communication and processing it will take longer to execute, regardless of the submission method.

Q: What's the difference between doGet() and doPost()?

A: The doGet() and doPost() methods are designed to handle HTTP GET and POST type requests respectively. When a GET request is submitted to a servlet container, it calls the doGet method of the servlet that handles the request via the service method.

The doGet() and doPost() methods both take the same arguments and will handle the servlet response in an equivalent manner, so for convenience a doPost() request can be passed to a doGet() method and vice-versa. However, bear in mind several properties of the servlet request object will be different for POST requests; it will not include a query string, and its getMethod() method will return "post".

Q: Must doPost() call doGet()?

A: There is no requirement for doGet() to call doPost() or vice versa. As a convenience some servlets are set up so their doPost() method calls doGet() because they are intended to handle GET and POST requests identically. If both methods called each other you would create an endless loop that would quickly throw an exception.

Q: Does the servlet request contain the source of the Web page?

A: The HttpServletRequest object contains all the key information for the HTTP request, not the source of the requested Web resource. Normally, JSP pages are compiled into servlets and processed automatically by the servlet container, so there is no need to write any additional processor code yourself. If you need to dynamically configure the servlet response, you should use JSP script elements or JSP tags in the body of the document and let the servlet container handle the processing.

If you really want to process the source of a static HTML document or suchlike, you can use the getResourceAsStream(String path) method of the ServletContext object to get an InputStream of the file.

More details available to subscribers:
Does the servlet request contain the source of the Web page?

Request dispatcher methods

Q: Why are there two different getRequestDispatcher() methods?

A: There is very little difference between the ServletContext and ServletRequest versions of this method, the RequestDispatcher you get operates in exactly the same way. However, the ServletRequest method also allows you to use a path argument that is relative to the "current" resource, starting with "./Example.jsp" or "../Example.jsp". The ServletContext getRequestDispatcher method should only be used for paths relative to the application root, starting with "/Example.jsp".

It generally avoids ambiguity and possible confusion to use a path relative to the application root.

Q: Why do I get a compilation error with getRequestDispatcher(String)?

A: This error means the compiler does not recognise this method signature in the context that you are calling it. The getRequestDispatcher method is not an HttpServlet method, it can only be called on a ServletRequest, HttpServletRequest or ServletContext object. For instance, you could use...

More details available to subscribers:
Why do I get a compilation error with getRequestDispatcher(String)?

Q: What's the difference between the include() and forward() methods?

A: The RequestDispatcher include() method inserts the contents of the specified resource directly in the flow of the servlet response, as if it were part of the calling servlet. If you include a servlet or JSP document, the included resource must not attempt to change the response status code or HTTP headers, any such request will be ignored. The include() method is often used to include common "boilerplate" text or template markup that may be included by many servlets.

The RequestDispatcher forward() method is used to show a different resource in place of the servlet that was originally called. The forwarded resource may be another servlet, JSP or static HTML document, but the response is issued under the same URL that was originally requested. In other words, it is not the same as a redirection. The forward() method is often used where a servlet is taking a controller role; processing some input and deciding the outcome by returning a particular response page.

Help request

Use the form below to submit a help request or general enquiry about the Code Style Web site. Read our guidelines on asking the right questions first.

Name:
Email*:
Example URL:
Comments:
Do NOT put any URLs here
Join mailing list:	Yes, join the mailing list No
* Required fields

Your email address will not be mis-used. If you include your address you may be sent a personal reply, you will not be added to any mailing list unless you request it. Read the site privacy statement for details.

Navigation

• Home page
• CSS style guide
  • Web font sampler
  • CSS media monitor
• Java & servlets
• Javascript & DOM
• HTML & XHTML
• Help and FAQs
• Site log

Site search

Home · CSS · Java · Javascript · HTML · Help · Log

Copyright © 2000-2008 Philip Shaw, all rights reserved, terms and conditions apply.
Valid XHTML and correct CSS. Last updated 27 July 2008 at 05:26:29 AM BST.
URI: http://codestyle.org/java/servlets/faq-API.shtml Metadata: RDF RSS 1.0