Jakarta Servlet

A Jakarta Servlet (formerly Java Servlet) is a Java software component that extends the capabilities of a server. Although servlets can respond to many types of requests, they most commonly implement web containers for hosting web applications on web servers and thus qualify as a server-side servlet web API. Such web servlets are the Java counterpart to other dynamic web content technologies such as PHP and ASP.NET.
Introduction.
A Jakarta Servlet processes or stores a Java class in Jakarta EE that conforms to the Jakarta Servlet API, a standard for implementing Java classes that respond to requests. Servlets could in principle communicate over any client–server protocol, but they are most often used with HTTP. Thus "servlet" is often used as shorthand for "HTTP servlet". Thus, a software developer may use a servlet to add dynamic content to a web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML and more commonly, JSON. Servlets can maintain state in session variables across many server transactions by using HTTP cookies, or URL mapping.
The Jakarta Servlet API has, to some extent, been superseded by two standard Java technologies for web services: 
To deploy and run a servlet, a web container must be used. A web container (also known as a servlet container) is essentially the component of a web server that interacts with the servlets. The web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights.
The Servlet API, contained in the Java package hierarchy , defines the expected interactions of the web container and a servlet.
A is an object that receives a request and generates a response based on that request. The basic Servlet package defines Java objects to represent servlet requests and responses, as well as objects to reflect the servlet's configuration parameters and execution environment. The package defines HTTP-specific subclasses of the generic servlet elements, including session management objects that track multiple requests and responses between the web server and a client. Servlets may be packaged in a WAR file as a web application.
Servlets can be generated automatically from Jakarta Server Pages (JSP) by the Jakarta Server Pages compiler. The difference between servlets and JSP is that servlets typically embed HTML inside Java code, while JSPs embed Java code in HTML. While the direct usage of servlets to generate HTML (as shown in the example below) has become rare, the higher level MVC web framework in Jakarta EE (JSF) still explicitly uses the servlet technology for the low level request/response handling via the . A somewhat older usage is to use servlets in conjunction with JSPs in a pattern called "Model 2", which is a flavor of the model–view–controller.
The current version of Servlet is 4.0.
History.
The Java Servlet API was first publicly announced at the inaugural JavaOne conference in May 1996. About two months after the announcements at the conference, the first public implementation was made available on the JavaSoft website. This was the first alpha of the Java Web Server (JWS; then known by its codename "Jeeves") which would eventually be shipped as a product on June 5, 1997.
In his blog on java.net, Sun veteran and GlassFish lead Jim Driscoll details the history of servlet technology. James Gosling first thought of servlets in the early days of Java, but the concept did not become a product until December 1996 when Sun shipped JWS. This was before what is now the Jakarta EE was made into a specification.
The Servlet1 specification was created by Pavni Diwanji while she worked at Sun Microsystems, with version 1.0 finalized in June 1997. Starting with version 2.2, the specification was developed under the Java Community Process.
Life cycle of a servlet.
Three methods are central to the life cycle of a servlet. These are codice_1, codice_2, and codice_3.
They are implemented by every servlet and are invoked at specific times by the server.
The following is a typical user scenario of these methods.
Example.
The following example servlet prints how many times its codice_2 method was called.
Note that codice_16 is a subclass of codice_17, an implementation of the codice_18 interface.
The codice_2 method of codice_16 class dispatches requests to the methods codice_21, codice_22, codice_23, codice_24, and so on; according to the HTTP request. In the example below codice_2 is overridden and does not distinguish which HTTP request method it serves.
import java.io.IOException;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class ServletLifeCycleExample extends HttpServlet {
 private Integer sharedCounter;
 @Override
 public void init(final ServletConfig config) throws ServletException {
 super.init(config);
 getServletContext().log("init() called");
 sharedCounter = 0;
 @Override
 protected void service(final HttpServletRequest request, final HttpServletResponse response) throws ServletException, IOException {
 getServletContext().log("service() called");
 int localCounter;
 synchronized (sharedCounter) {
 sharedCounter++;
 localCounter = sharedCounter;
 response.getWriter().write("Incrementing the count to " + localCounter); // accessing a local variable
 @Override
 public void destroy() {
 getServletContext().log("destroy() called");
Container servers.
The specification for Servlet technology has been implemented in many products. See a list of implementations on the web container page.