2.3 How Servlet Works?

How servlet works? As we know, servlets don't have a main() method.

	This raises a question; who creates a servlet instance? What makes a servlet object different from any other
	object?

	Also if you look at doGET() method in Hello servlet example, you will notice that it accepts two parameters
	HTTPServletRequest and HTTPServletResponse,

	Who creates those objects and passes them to a servlet doGET() method? Who manages the life and death of
	a servlet? Did you get the answer? It is a web container.

What is a container?

	Web container (also known as a Servlet container) is the component of a web server that interacts with servlets
	and manages its lifecycle.

Tomcat is an example of a Container.

	When your web server application (like Apache) gets a request for a servlet (as opposed to, say, a plain old
	static HTML page), the server hands the request not to the servlet itself, but to the Container in which the servlet
	is deployed.

2.3 How Servlet Works?

	It's the Container that gives the servlet the HTTP request and response, and it's the Container that calls the
	servlet's methods (like doPost() or doGet()) (Bates, Sierra and Basham 2008).

Figure 2.10: How servlet works

Figure 2.10 illustrate how servlet works, the browser sends requests to the web server.

If the target is an HTML file, the server handles it directly.

	If the target is a servlet, the server delegates the request to the servlet container, which in turn forwards it to the
	servlet.

2.3 How Servlet Works?

	The servlet uses the file-system where. HTML files are stored and database where business data is stored to
	generate dynamic output (SCARPINO, et al. 2005).

Container functions

Communications support:

The container provides an easy way for your servlets to talk to your web server.

You don't have to build a ServerSocket, listen on a port, create streams, etc.

		The Container knows the protocol between the web server and itself, so that your servlet doesn't have to
		worry about an API between, say, the Apache web server and your own web application code.

		All you have to worry about is your own business logic that goes in your Servlet (like accepting an order from
		your online store) (Bates, Sierra and Basham 2008).

Lifecycle Management:

The container controls the life and death of your servlets.

		It takes care of loading the classes, instantiating and initializing the servlets, invoking the servlet methods,
		and making servlet instances eligible for garbage collection.

2.3 How Servlet Works?

		With the Container in control, you don't have to worry as much about resource management (Bates, Sierra
		and Basham 2008).

Multithreading support:

The container automatically creates a new Java thread for every servlet request it receives.

		When the servlet's done running the HTTP service method for that client's request, the thread completes
		(i.e. dies).

This doesn't mean you're off the hook for thread safety-you can still run into synchronization issues.

		But having the server create and manage threads for multiple requests still saves you a lot of work (Bates,
		Sierra and Basham 2008).

Declarative security:

		With a container, you get to use an XML deployment descriptor to configure (and modify) security without
		having to hard-code it into your servlet (or any other) class code.

		Think about that! You can manage and change your security without touching and recompiling your Java
		source files (Bates, Sierra and Basham 2008).

2.3 How Servlet Works?

	JSP support: you already know how cool JSPs are. Well, who do you think takes care of translating that JSP
	code into real Java? Of course. The Container (Bates, Sierra and Basham 2008).

How the Container handles a request

Provides an excellent overview of how the container handles a user request:

User clicks a link that has a URL to a servlet instead of a static page (figure 2.11):

Figure 2.11

2.3 How Servlet Works?

The container "sees" that the request is for a servlet, so the container creates two objects (figure 2.12):

HttpServletResponse

HttpServletRequest

Figure 2.12

2.3 How Servlet Works?

		The container finds the correct servlet based on the URL in the request, creates or allocates a thread for that
		request, and passes the request and response objects to the servlet thread (figure 2.13).

Figure 2.13

2.3 How Servlet Works?

		The container calls the servlet's service() method. Depending on the type of request, the service() method
		calls either the doGet() or doPost() method. For this example, we'll assume the request was an HTTP GET
		(figure 2.14).

Figure 2.14

2.3 How Servlet Works?

		The doGet() method generates the dynamic page and stuffs the page into the response object. Remember,
		the container still has a reference to the response object (figure 2.15).

Figure 2.15

2.3 How Servlet Works?

		The thread completes, the container converts the response object into an HTTP response, sends it back to
		the client, then deletes the request and response objects (figure 2.16).

Figure 2.16

2.3 How Servlet Works?

Deployment Descriptor (DD)

	How the container found the correct servlet? How does it map the URL entered by user to the correct servlet?
	The answer is Deployment Descriptor.

The Deployment Descriptor or DD is simple XML document.

It must conform to the XML standard.

This means it should start with the XML declaration (<?xml version="1.0"?>).

The root element of the deployment descriptor is the <web-app> element.

Table 2.2 shows some of the subelements that can be used within the <web-app> element.

Under the Servlet 2.4 specification, these elements can occur in any order within the deployment descriptor.

2.3 How Servlet Works?

Table 2.2: Valid Subelements for the <web-app> Element of a Deployment Descriptor

	We will take a closer look at some of the most important subelements: <context-param>, <servlet>, and
	<servlet-mapping>.

The <context-param> Element

		The <context-param> element allows you to define context parameters. These parameters specify values
		that are available to the entire web application context (Mukhar, et al. 2006).

2.3 How Servlet Works?

The element is used like this:

The deployment descriptor can contain zero or more of these elements.

Each web component that has access to the Servlet context can access these parameters by name.

		Note that because the web.xml file is in text format, you can pass parameters to the application only as
		strings (Mukhar, et al. 2006).

The <servlet> Element

The <servlet> element is the primary element for describing the Servlets in your web application.

The <servlet> element can have the following sub elements:

<icon>

<servlet-name>

2.3 How Servlet Works?

<display-name>

<description>

<servlet-class>

<jsp-file>

<init-param>

<load-on-startup>

<run-as>

<security-role-ref>

The only required sub elements are and one of the sub elements <servlet-class> or <jsp-file>.

The <servlet-name> sub element defines a user-friendly "nickname" name that can be used for the resource.

		The <servlet-class> or <jsp-file> subelement defines the fully qualified name of the Servlet class or JSP file,
		usually it is chosen by the developer of servlet class.

		In Hello World servlet example in figure 2.3, we used the following for the <servlet> element (Mukhar, et al.
		2006):

2.3 How Servlet Works?

		By defining the Servlet name as Hello, and using the element to map URLs such as /Hello to the name
		Hello, we were able to access the Servlet using the simple URL /Servlet/Hello.

		Okay, that's not such a big deal when the Servlet name and class name are both Hello, but suppose your
		class name were com.mycompany.subdivision.MyServletWith.AReallyReallyLongName.

		Do you really want to type that? It makes much more sense to be able to access the Servlet using
		SimpleName (Mukhar, et al. 2006).

		The other sub element of <servlet> that you will use often is <init-param>. The <init-param> element is
		similar to the <context-param> element.

		The difference is that <init-param> defines parameters that are accessible only to the given Servlet (Mukhar,
		et al. 2006).

2.3 How Servlet Works?

Here's an example:

The <servlet-mapping> Element

		The <servlet-mapping> element is used to define mappings from a particular request URI to a given Servlet
		name (Mukhar, et al. 2006).

In Hello World servlet example in figure 2.3, we defined the following mapping:

		This told the server that if it received any URI that matched the pattern /Hello, it should pass the request to
		the Servlet with the name Hello.

2.3 How Servlet Works?

The multiple names of the servlet improve your application flexibility and security.

		What happen if there was such mapping, you have to hard-code the real path of servlet in every JSPs and
		other HTML pages that use that servlet.

		Now what happens when you need to reorganize your application (e.g. move a servlet to different directory)?
		You have to modify all files that use that servlet to reflect the new path.

		By servlet mapping all you have to do is to change the actual path of servlet only without having the
		maintenance nightmare of tracking down all files that refer to old location of a servlet.

Also by mapping the name of servlet, you protect your application.

		If the client knows the actual path of servlet, then he can navigate directly to it without going through right
		pages or forms.

		In order to map the browser URL into deployment name "secret name" of servlet <servlet-mapping> is used,
		while <servlet> element is used to map that "secret name" to the actual servlet class (figure 2.8).