Understanding Servlet API Anatomy

If you have started learning how to develop web applications with servlets, then you must have the idea that servlets are Java programs written on the server side and from the perspective of a Java developer, you might have some discrete knowledge of Servlet API specially HttpServlet

In this tutorial, we will be assisting you in getting complete knowledge of Servlet API. We would like to recommend going through the original Servlet API documentation side by side while reading this tutorial.
Let's proceed

---

Servlet API

Servlet API is mainly driven by two packages javax.servlet and javax.servlet.http

javax.servlet package holds numerous interfaces and classes that describe a protocol-neutral servlet along with its container environment. The term protocol neutral essentially means that being a programmer, you are not restricted to writing HttpServlet only, if your situation demands then you can write servlets for other protocols like FtpServlet, etc. as well just by implementing an Interface called Servlet within javax.servlet package.

---

javax.servlet package has the following fourteen Interfaces like

• Servlet
• ServletRequest
• ServletResponse
• ServletContext
• ServletConfig
• RequestDispatcher
• ServletContextListner
• ServletContextAttributeListener
• ServletRequestListner
• ServletRequestAttributeListener
• SingleThreadModel
• Filter
• FilterChain
• FilterConfig

---

Interface javax.servlet.Servlet

Out of these fourteen interfaces, the Servlet interface lists all the methods that every servlet (irrespective of its type) must implement. These methods are

• void init(ServletConfig config)
• void service(ServletRequest req, ServletResponse res)
• void destroy()
• ServletConfig getServletConfig(); and
• String getServletInfo()

So, if you wish, you can write your own servlet by implementing the interface javax.servlet.Servlet , thereby concretizing these five methods on your own. It is noteworthy, that till this point, there is no consideration of any specific protocol which defines how your request data are coming from the client to the server.

---

To make your life easy, Java guys have designed an abstract class GenericServlet within javax.servlet package. This class, obviously being protocol independent, implements javax.servlet.Servlet interface and hence defines some methods useful for writing your own servlet.

So once again if you wish to write your own specific servlet, you can extend this javax.servlet.GenericServlet abstract class.

---

Abstract Class javax.servlet.GenericServlet

GenericServlet implements javax.servlet.Servlet and javax.servlet.ServletConfig interfaces. It is an abstract class having twelve methods out of which, eleven are already concrete (having their own definition) and only one is left as abstract. This abstract class can be extended by any servlet (developed by you)as long as it has no inclination toward specific protocols. Below are some notable methods along with their nature.

• void service(ServletRequest req, ServletResponse res) -- abstract in nature
• void init(ServletConfig config) -- non-abstract in nature
• void init() -- non-abstract in nature
• void destroy() -- non-abstract in nature

---

Abstract service method has to be defined by the servlet which extends GenericServlet . The service method will serve the incoming request data from the client wrapped under the object of javax.servlet.ServletRequest and generates the outcome and wraps it within the object of javax.servlet.ServletResponse . Hence if you are trying to write a servlet of your own and if you decide this servlet to extend javax.servlet.GenericServlet , then you, as a developer, have to write the body of service method

void init(ServletConfig config) has already been defined in javax.servlet.GenericServlet . It is called by the container to notify that a servlet has been initialized and placed.

void init() is also defined in the javax.servlet.GenericServlet . This is basically a convenience method and it should be used by any extending class for any initialization purposes. The introduction of this method lets all the extending classes not to call init(ServletConfig config) method  javax.servlet.Servlet through super .

The void destroy() method is already defined in javax.servlet.GenericServlet . This method is called by the container to notify that the servlet is being relinquished from the memory and can not serve incoming requests wrapped around ServletRequest object.

---

On the basis of the above discussion, it is pretty much clear that, if you, as a developer, want to develop your own protocol-independent servlet, then you can extend javax.servlet.Genericservlet which in turn implements javax.servlet.Servlet . While writing this servlet, you have to override the void service(servletRequest req, ServletResponse res) method in order to incorporate your own buisness logic.

But, in the current scenario, clients send requests to the server mostly with HTTP protocol, and hence in that context, you might be more interested to write a servlet with HTTP support instead of writing a protocol-neutral servlet. In that case, writing a servlet that extends a GenericServlet will not be of much help.

luckily, Java designers have provided another abstract class HttpServlet in another package called javax.servlet.http . Let us discuss a bit on this HttpServlet so that you can have a clear understanding of what you mostly write as Java servlets.

---

Abstract class javax.servlet.http.HttpServlet

In general, javax.servlet.http package contains multiple classes and interfaces which govern the way a servlet class behaves running under the HTTP protocol and allied runtime environment.

HttpServlet is an abstract class defined in javax.servlet.http.HttpServlet which extends javax.servlet.GenericServlet . It is designed in a way such that developers can just extend it and can readily write a servlet best suited for any web application. It is noteworthy to say that even if HttpServlet is an abstract class, all the methods of it are concrete. Among many other defined methods, service method which descends down from the javax.servlet.GenericServlet , needs a special mention.

If you are trying to write a servlet under Http protocol, you would readily extend the HttpServlet . Now the incoming request (wrapped under javax.servlet.http.HttpRequest ) would first be served by the service method of your servlet. This service method should not be overridden at the subclass level. The original service method of HttpServlet will examine the inconming HttpRequest object and depending upon the HTTP header structure it will call any of the doxxx methods which are also defined in HttpServlet . At the subclass level, your HTTP capable servlet which extends HttpServlet should accordingly override the appropriate doxxx method as per your business logic.

For example, if your client is making a GET HTTP request, then the service method of HttpServlet will call your overridden doGet method.

---

Hence, while extending an HttpServlet , please keep in mind that there is no point in overriding service method of HttpServlet as it will ultimately call a doxxx method; and you have to override at least one doxxx method as per your application requirement.

The understanding of Servlet API will never be complete until we resolve a very legitimate doubt that if all the methods of HttpServlet are concrete, then why Httpservlet is designed as an abstract one.
The following discussion will help you understand the idea.

---

Why HttpServlet is designed as abstract even if all the methods are concrete?

We know that in Java, an abstract class can not be instantiated but it can be extended. It hardly matters for that abstract class whether all or none of its methods are abstract. So technically there is no harm in declaring HttpServlet as an abstract class even if none of its methods are abstract. But we need to understand its design implications.

If HttpServlet was not abstract, then anybody could have instantiated its object. From the design perspective, it is meaningless as from a functional point of view HttpServlet does nothing on its own (all its doxxx methods are nonfunctional unless they are overridden). So it was a necessity that nobody could instantiate HttpServlet even by mistake.

Another doubt might creep up in the process why, not all the doxxx methods of HttpServlet are abstract especially when there was a chance of declaring them as abstract as HttpServlet itself was already declared as abstract?

If it was done, then as a developer you had to concretize all those doxxx methods on your own and you had to put the logic in any one of them (depending on your application's demand), leaving others as non-functional. 

This would become tedious for the developer and could lead to the source of further unexpected or erroneous behavior of your application. Hence the way HttpServlet is designed to seem quite logical.

---

So, we are at the end and we hope that you have enjoyed this tutorial.

Happy Exploring!