1. Http. Servlets are actually generic components designed to support any sort of operation that operates in a request/response cycle. That mostly means HTTP, but ages ago, IBM mainframes routinely did their online apps in a framework known as CICS (Customer Information Control System). It didn't use tcp/ip (not invented yet), and it didn't use HTML or HTTP (also not invented yet), but it was (mostly) request/response. So had servlets - or Java - existed back then, they would have been appropriate.
What an HttpServlet adds to the core servlet class is support for things specific to HTTP. For example, how URLs are processed, the difference between request types (GET, POST, HEAD, DELETE and so forth).
Don't forget that all of the above are Interfaces, not classes, so the server's specific implementation class will implement the interface, but its properties and behaviours above and beyond what those interfaces demand are server-specific.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Feb 20, 2013
Thanks for the reply Tim but still i am not get it clearly .
According to me GenericServlet is an Abstract class which implements interfaces like servlet & servletConfig & this class implements all the abstract methods of the interfaces it implements except the Service(Servletrequest, ServletResponse) method. This is because to keep GenericServlet class common to all the type of request protocols. Now, HttpServlet class which is also an abstract cl;ass extends genericServlet class and implements the service method in it. In this service method there is Http protocol specfic code which enables the servlet to handle Http requests. And this HttpServlet class is the class which we extend in our Servlet class..
Probably the most important feature that HttpServlet adds to GenericServlet is that its implementation of the service() method looks at the incoming URL and dispatches it to a service-specific HttpServlet overridable method. For example, a GET gets dispatched to goGet(), a POST to doPost(), and so forth.
So the webapp server (Tomcat, in this case) wouldn't need to do a lot of constructing and re-constructing. Just create its native objects according to the J2EE spec and everything takes care of itself.