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.

Life of a JSP file

Introduction

A Jakarta Servlet processes or stores a Java class in Jakarta EE that conforms to the Jakarta Servlet API,[1] 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".[2] 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:

• the Jakarta RESTful Web Services (JAX-RS 2.0) useful for AJAX, JSON and REST services, and
• the Jakarta XML Web Services (JAX-WS) useful for SOAP 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 javax.servlet, defines the expected interactions of the web container and a servlet.[2]

A Servlet 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 javax.servlet.http 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 FacesServlet. 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.[3]

History

The Java Servlet API was first publicly announced at the inaugural JavaOne conference in May 1996.[4][5] 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)[6] which would eventually be shipped as a product on June 5, 1997.[7]

In his blog on java.net, Sun veteran and GlassFish lead Jim Driscoll details the history of servlet technology.[8] 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.[9][10][11] This was before what is now the Jakarta EE was made into a specification.

The Servlet1 specification was created by Pavni Diwanji[12][13] 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.

Servlet API history

Servlet API version	Released	Specification	Platform	Important Changes
Jakarta Servlet 5.0.0 M1	Jun 12, 2020	5.0	Jakarta EE 9	API moved from package javax.servlet to jakarta.servlet
Jakarta Servlet 4.0.3	Aug 13, 2019	4.0	Jakarta EE 8	Renamed from "Java" trademark
Java Servlet 4.0	Sep 2017	JSR 369	Java EE 8	HTTP/2
Java Servlet 3.1	May 2013	JSR 340	Java EE 7	Non-blocking I/O, HTTP protocol upgrade mechanism (WebSocket)[14]
Java Servlet 3.0	December 2009	JSR 315	Java EE 6, Java SE 6	Pluggability, Ease of development, Async Servlet, Security, File Uploading
Java Servlet 2.5	September 2005	JSR 154	Java EE 5, Java SE 5	Requires Java SE 5, supports annotation
Java Servlet 2.4	November 2003	JSR 154	J2EE 1.4, J2SE 1.3	web.xml uses XML Schema
Java Servlet 2.3	August 2001	JSR 53	J2EE 1.3, J2SE 1.2	Addition of Filter
Java Servlet 2.2	August 1999	JSR 902, JSR 903	J2EE 1.2, J2SE 1.2	Becomes part of J2EE, introduced independent web applications in .war files
Java Servlet 2.1	November 1998	2.1a	Unspecified	First official specification, added RequestDispatcher, ServletContext
Java Servlet 2.0	December 1997	N/A	JDK 1.1	Part of April 1998 Java Servlet Development Kit 2.0[15]
Java Servlet 1.0	December 1996	N/A		Part of June 1997 Java Servlet Development Kit (JSDK) 1.0[9]

Life cycle of a servlet

Three methods are central to the life cycle of a servlet. These are init(), service(), and destroy(). They are implemented by every servlet and are invoked at specific times by the server.

• During initialization stage of the servlet life cycle, the web container initializes the servlet instance by calling the init() method, passing an object implementing the javax.servlet.ServletConfig interface. This configuration object allows the servlet to access name-value initialization parameters from the web application.
• After initialization, the servlet instance can service client requests. Each request is serviced in its own separate thread. The web container calls the service() method of the servlet for every request. The service() method determines the kind of request being made and dispatches it to an appropriate method to handle the request. The developer of the servlet must provide an implementation for these methods. If a request is made for a method that is not implemented by the servlet, the method of the parent class is called, typically resulting in an error being returned to the requester.
• Finally, the web container calls the destroy() method that takes the servlet out of service. The destroy() method, like init(), is called only once in the lifecycle of a servlet.

The following is a typical user scenario of these methods.

1. Assume that a user requests to visit a URL.
   • The browser then generates an HTTP request for this URL.
   • This request is then sent to the appropriate server.
2. The HTTP request is received by the web server and forwarded to the servlet container.
   • The container maps this request to a particular servlet.
   • The servlet is dynamically retrieved and loaded into the address space of the container.
3. The container invokes the init() method of the servlet.
   • This method is invoked only when the servlet is first loaded into memory.
   • It is possible to pass initialization parameters to the servlet so that it may configure itself.
4. The container invokes the service() method of the servlet.
   • This method is called to process the HTTP request.
   • The servlet may read data that has been provided in the HTTP request.
   • The servlet may also formulate an HTTP response for the client.
5. The servlet remains in the container's address space and is available to process any other HTTP requests received from clients.
   • The service() method is called for each HTTP request.
6. The container may, at some point, decide to unload the servlet from its memory.
   • The algorithms by which this decision is made are specific to each container.
7. The container calls the servlet's destroy() method to relinquish any resources such as file handles that are allocated for the servlet; important data may be saved to a persistent store.
8. The memory allocated for the servlet and its objects can then be garbage collected.

Example

The following example servlet prints how many times its service() method was called.

Note that HttpServlet is a subclass of GenericServlet, an implementation of the Servlet interface.

The service() method of HttpServlet class dispatches requests to the methods doGet(), doPost(), doPut(), doDelete(), and so on; according to the HTTP request. In the example below service() 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.

References

1. "Servlet (Java(TM) EE 7 Specification APIs)". oracle.com. Retrieved 2018-07-25.
2. "Servlet Essentials - Chapter 1". novocode.com. Archived from the original on 2017-12-18.
3. https://jcp.org/en/jsr/detail?id=369
4. Freedman, Matt (June 26, 1996). "JavaOne conference report". JavaWorld.
5. Diwanji, Pavani; Connelly, Dave; Wagle, Prasad (May 29, 1996). "Java Server and Servlets". Servers and Server Extensions (PDF). JavaOne 1996. Archived (PDF) from the original on 2000-08-16. Retrieved 2020-02-01.
6. Chang, Phil Inje (July 1, 1997). "Interview: The Java Web Server team gives you the skinny". JavaWorld. Retrieved 2018-07-25.
7. Chang, Phil Inje (June 1, 1997). "Java Web Server ships!". JavaWorld. Retrieved 2018-07-25.
8. "Servlet History | community.oracle.com". Weblogs.java.net. 2005-12-10. Retrieved 2013-06-14.
9. Hunter, Jason (March 2000). "Servlet Timeline". Beyond Java Servlet Programming. O'Reilly Conference on Java. O'Reilly Media.
10. "Java Web Server". Javasoft. Sun Microsystems. Archived from the original on 1998-01-11. Retrieved 2020-02-01.
11. "Java Web Server(tm)". Sun Microsystems. Archived from the original on 2002-02-06. Retrieved 2020-02-01.
12. "Pavni Diwanji". Family Online Safety Institute. Retrieved 12 November 2016.
13. US patent 5928323, Gosling, James A.; Pavni Diwanji & David W. Connelly, "Apparatus and method for dynamically generating information with server-side software objects", published 1999-07-27, issued 1999-07-27, assigned to Sun Microsystems
14. "What's new in Servlet 3.1 ? - Java EE 7 moving forward (Arun Gupta, Miles to go ...)". oracle.com. Retrieved 22 November 2016.
15. Crawford, William; Hunter, Jason (November 1998). "Preface". Java Servlet Programming (1st ed.). O'Reilly Media. p. ix–x. ISBN 978-1-56592-391-1. We cover Version 2.0 of the Servlet API, which was introduced as part of the Java Web Server 1.1 in December 1997 and clarified by the release of the Java Servlet Development Kit 2.0 in April 1998.

External links

• Official website
• Servlets.com