This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
Original author(s) | Pavni Diwanji |
---|---|
Developer(s) | Eclipse Foundation |
Initial release | December 1996 (1996-12) |
Stable release | 6.0 / May 31, 2022 (2022-05-31) |
Repository |
|
Written in | Java |
Platform | Jakarta EE |
Size | 2.56 MB |
Type | Software component for Web API |
License | Eclipse Public License |
Website | jakarta.ee/specifications/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.
A Jakarta Servlet is a Java class[1] in Jakarta EE that conforms to the Jakarta Servlet API,[2] 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. In principle, any servlets can extend the GenericServlet
class; however, realistically speaking, all servlets extend the HttpServlet
class.[3] Thus "servlet" is often used as shorthand for "HTTP servlet".[4] Thus, a servlet can be used to add dynamic content to a web server using the Java platform.[5] The generated content is commonly HTML, but may be other data such as XML and more commonly, JSON.
The Jakarta Servlet API has, to some extent, been superseded[citation needed] by two standard Java technologies for web services:
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 Servlet API, contained in the Java package hierarchy javax.servlet
, defines the expected interactions of the web container and a servlet.[4]
The package javax.servlet.http
defines HTTP-specific subclasses of the GenericServlet
. This package includes session management objects that track multiple requests and responses between the web server and a client.
Servlets can maintain state in session variables across many server transactions by using HTTP cookies, or URL mapping.[6] There are several ways of creating a servlet and using URL mapping with a servlet. Before servlet 3.0 specification (Tomcat 7.0), configuring the web.xml to map a servlet to a URL was the only option. For applications using the servlet 3.0 specification or later, the @WebServlet
annotation can be used to map any servlet to one or more URL patterns.
Servlets may be packaged in a WAR file as a web application.[7]
A web container is required for deploying and running a servlet. A web container (also known as a servlet container) is essentially the component of a web server that interacts with the servlets.[1] 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.
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. In general, when using JSPs, embedding Java code in JSP is considered bad practice.[8] Instead, a better approach would be to move the back-end logic from the JSP to the Java code in the Servlet
.[8] This ensures that the Servlet
is only responsible for processing, and the JSP is only responsible for presenting the HTML,[8] allowing for a clear separation of concerns and conformance to the single-responsibility principle.
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 (Faces) 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 Java Servlet API was first publicly announced at the inaugural JavaOne conference in May 1996.[9][10] 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)[11] which would eventually be shipped as a product on June 5, 1997.[12]
In his blog on java.net, Sun veteran and GlassFish lead Jim Driscoll details the history of servlet technology.[13] 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.[14][15][16] This was before what is now the Jakarta EE was made into a specification.
The Servlet1 specification was created by Pavni Diwanji[17][18] 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 version | Released | Specification | Platform | Important Changes |
---|---|---|---|---|
Jakarta Servlet 6.0 | May 31, 2022 | 6.0 | Jakarta EE 10 | remove deprecated features and implement requested enhancements |
Jakarta Servlet 5.0 | Oct 9, 2020 | 5.0 | Jakarta EE 9 | API moved from package javax.servlet to jakarta.servlet |
Jakarta Servlet 4.0.3 | Sep 10, 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)[19] |
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 | — | JDK 1.1 | Part of April 1998 Java Servlet Development Kit 2.0[20] |
Java Servlet 1.0 | December 1996 | — | Part of June 1997 Java Servlet Development Kit (JSDK) 1.0[14] |
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.
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.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.
init()
method of the servlet.service()
method of the servlet.service()
method is called for each HTTP request.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.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 jakarta.servlet.ServletConfig;import jakarta.servlet.ServletException;import jakarta.servlet.http.HttpServlet;import jakarta.servlet.http.HttpServletRequest;import jakarta.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 response.getWriter().flush(); // flush response } @Override public void destroy() { getServletContext().log("destroy() called"); }}
The specification for Servlet technology has been implemented in many products. See a list of implementations on the web container page.
There are also other types of servlet containers such as those for SIP servlets, e.g., SailFin.
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.