Pluggable implementations are normally designed around Interfaces.
Servlets are no different. They are pluggable implementations with a predefined lifecycle.
Create/Service/...../Destroy.
Servlet-Container considers for Servlets only those classes which implements javax.servlet.Servlet Interface. Each Servlet
implements this interface indirectly. We normally dont come across "implements javax.servlet.Servlet"
because it is already done for us up in the inheritance hierarchy.
We make use of the helper implementations of either the abstract java.servlet.http.HttpServlet by way of extending it in our
servlet implementation; which in turn extends javax.servlet.GenericServlet.
if you look at the class signature of the javax.servlet.GenericServlet , you will find that this abstract
class implements the javax.servlet.Servlet Interface, and tells the Servlet-container that I'm a Servlet.
Once the servlet-container knows something is a servlet. it knows what to do with it , because of the contract between the Servlet-container and
the implementing class established using the Interface.
While defining the interface there is no way for the designers to know what would be the signature of the
constructor of the implementing Servlet classes, and in turn enforce the contract , and make the Servlet-container call these constructors.
( Unless it resorts to reflection API to find out the constructor signature
and call them, at a drastic loss in performance )
So you have predefined methods for the lifecycle of the servlet, which the Servlet-container calls appropriately
during various stages of processing of the servlet.
As for the constructor the default constructor is anyways called.
You can create a constructor for the servlet with
ServletConfig as the parameter. But you have NO WAY way of telling the servlet container to call this method because it
does not happen to be part of the contract, and would be ignored.
