{"id":101,"date":"2018-07-11T05:33:13","date_gmt":"2018-07-11T05:33:13","guid":{"rendered":"http:\/\/itp16.epgpbooks.inflibnet.ac.in\/?post_type=chapter&p=101"},"modified":"2019-05-15T07:17:47","modified_gmt":"2019-05-15T07:17:47","slug":"the-servlet-life-cycle","status":"publish","type":"chapter","link":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/chapter\/the-servlet-life-cycle\/","title":{"rendered":"The Servlet Life Cycle"},"content":{"raw":"
\"epgp<\/a>\r\n<\/span><\/div>\r\n \r\n

What is a servlet?<\/strong><\/p>\r\n \r\n

Servlet is a server side component which receives a request from a client, processes the request and sends a content based response back to the client. The Servlet is a separate API, it is not part of the standard Java API. The Servlet as it runs on the server side, is embedded inside a Server. Most commonly the servlets are used for HTTP protocol, and \u00a0are \u00a0embedded \u00a0inside \u00a0a WebContainer. Common implementations of the Servlet specifications are Glassfish, Tomcat, jRun, jBoss, Jetty, etc.. Tomcat used to be the reference implementation for the servlet specifications, since Servlet specifications 3.0, Glassfish is the reference implementation. The Servlet specifications are managed independent of the standard Java specifications. There was a major standardization in the Servlet specifications version 2.0. It standardized the directory structure for deployment of the Servlet and related components, and introduced the concept of a web application. current specification is version 3.0.<\/p>\r\n \r\n

The Servlet specification is designed in generic way for any server which uses request response based protocol. There are 2 packages in the servlet API<\/p>\r\n\r\n

    \r\n \t
  1. javax.servlet, which is generic, and<\/li>\r\n \t
  2. javax.servlet.http, which is an extension of the generic APIs in the javax.servlet, and specific to HTTP protocol.<\/li>\r\n<\/ol>\r\n \r\n

    Servlet specifications mandate the implementations to support HTTP protocol. An implementation can also support other protocols, e.g., there are implementations which also support the \u00a0SIP protocol.<\/p>\r\n \r\n

    So in general a servlet is a component which is embedded inside some ServletContainer This is something similar to an Applet being embedded inside a Browser. which is a container for the Applet.<\/p>\r\n \r\n

    Number of servlets can be configured in a single web application. In turn several web applications may be deployed on a single instance of a WebContainer.<\/p>\r\n \r\n

    Architecture Diagram:<\/strong><\/p>\r\n

    \"\"<\/p>\r\n\r\n

    \r\n\r\n \r\n

    The life-cycle of a Servlet is controlled by the container in which the Servlet has been configured as part of a deployed web application.<\/p>\r\n \r\n

    The configuration of a web application maps URL patterns to Servlets.<\/p>\r\n \r\n

    When a ServletContainer starts, it would first look for all the deployed web applications. Then it would create an instance of ServletContext corresponding to each web application, similar to an AppletContext being created for each html page containing any applet tag inside a browser.<\/p>\r\n \r\n

    It would then find out the Servlets which are configured in web application. A Servlet may \u00a0be configured to be loaded at the \u00a0startup \u00a0of \u00a0web \u00a0application. \u00a0For \u00a0each \u00a0servlet \u00a0configured \u00a0to \u00a0be loaded on startup, it\u00a0 would create an instance of ServletConfig, similar to an AppletStub being created for each Applet in the html page inside a browser. These Servlet instances \u00a0are \u00a0then initialized by invoking init() method and passing corresponding ServletConfig instance.<\/p>\r\n \r\n

    When a request arrives from a client, based on the URL, Servlet would \u00a0be \u00a0identified \u00a0and \u00a0the following steps would be performed on the identified Servlet :<\/span><\/p>\r\n\r\n<\/div>\r\n

      \r\n \t
    1. If an instance of the Servlet does not exist, the web container (this may happen for Servlets which are not configure to load at startup) :\r\n
        \r\n \t
      1. Loads the Servlet class.<\/li>\r\n \t
      2. Creates an instance of the Servlet class.<\/li>\r\n \t
      3. Creates an instance of ServletConfig based on configuration information related to this Servlet.<\/li>\r\n \t
      4. Initializes the Servlet instance by calling the init() method. The aforesaid ServletConfig instance is passed to init() method.<\/li>\r\n<\/ol>\r\n<\/li>\r\n<\/ol>\r\n
          \r\n \t
        1. Invokes the service method, passing request and response objects.<\/li>\r\n \t
        2. If it needs to take the servlet out of service, the container finalizes the servlet by calling the Servlet\u2019s destroy() method.<\/li>\r\n<\/ol>\r\n
          \r\n

          Creating and Initializing a Servlet<\/strong><\/p>\r\n \r\n

          The web container initializes a servlet after loading and instantiating the servlet class and before delivering requests from clients. To customize this process to allow the servlet to read persistent configuration data, initialize resources, and perform any other one-time activities. If it cannot complete its initialization process, a servlet throws an UnavailableException.<\/p>\r\n \r\n

          A Servlet can be configured with initialization parameters which are made available to the Servlet through ServletConfig object. Initialization parameter can be\u00a0 used to provide data needed by a particular servlet..<\/p>\r\n \r\n

          Web container would create instance of the deployed Servlet using its default constructor. Next it would invoke the first method on the instance of Servlet. This method is the init() method. similar to the<\/p>\r\n \r\n\r\nvoid setStub(AppletStub stub)\r\n\r\nof the Applet.\r\n\r\nHere the init() method also has a parameter which is the ServletConfig.\r\n\r\n \r\n\r\nvoid init(ServletConfig cfg) throws ServletException\r\n\r\nSo the first life cycle method of a Servlet is init. Servlet<\/span>\r\n\r\n<\/div>\r\n

          In case the init() method invocation on a Servlet fails by throwing a ServletException, the \u00a0web container would take the Servlet out of service. The init() method may also fail by throwing UnavailableException ( sub-class of ServletException). The UnavailableException may indicate a duration for unavailability. In such case, the web container may recreate Servlet and try initialization again after the specified duration.<\/p>\r\n \r\n

          Request Processing<\/strong><\/p>\r\n \r\n

          The request processing for a servlet is handled by its service method. The term service method is used for any method in a servlet class that provides a service to a client.<\/span><\/p>\r\n \r\n

          After startup of web container is completed, it becomes ready to accept requests from client and give response back to the client. When a request arrives from the client, the web container first identifies the servlet for which this request has arrived based on URL. It would then encapsulate information available in the client request in an instance of ServletRequest. It would also allocate a Buffer and encapsulate it in an instance of ServletResponse. This Buffer is to be used by the Servlet to write the content which it wants to send back to the client. After creating the instance of ServletRequest and ServletResponse, it now invokes the service method on the instance of Servlet.<\/span><\/p>\r\n \r\n

          void service(ServletRequest request, ServletResponse response) throws ServletException, IOException<\/span><\/p>\r\n \r\n

          So the implementation of the service method by the Servlet is supposed to look at the information in the ServletRequest object, do some processing and then setup a response content in the buffer of the ServletResponse object. Once the service method is over, web container sends the content available in the buffer according to the protocol.<\/span><\/p>\r\n \r\n

          In case the service() method invocation on a Servlet fails by throwing a ServletException, the web container would first invoke destroy() on the Servlet and then takes it out of service. The service() method may also fail by throwing UnavailableException ( sub-class of ServletException). Here also the web container would first invoke destroy() on the Servlet and then takes it out of service. The UnavailableException may indicate a duration for unavailability. In such case, the\u00a0 web container may recreate Servlet and try initialization again after \u00a0the \u00a0specified \u00a0duration \u00a0to \u00a0bring \u00a0it \u00a0back \u00a0to ready for request processing.<\/span><\/p>\r\n \r\n

          If any request is received by web container for the Servlet which is out of service, web container\u00a0<\/span>directly gives appropriate negative response to the client without trying to invoke the service()\u00a0<\/span>method.<\/span><\/p>\r\n \r\n

          Finalizing a Servlet<\/strong><\/p>\r\n \r\n

          All web containers (Servlet containers) provide administrative tools to manage the deployment and other activities related to web application such as start, stop, undeploy etc. When an application is stopped or restarted, then the Servlet Container would destroy all the Servlet instances created for that application. The Servlet Container invokes the destroy() method before it destroys the Servlet instance.<\/p>\r\n \r\n

          Whenever the web container determines that a servlet should be removed from \u00a0service \u00a0(for example, when a container wants to reclaim memory resources or when it is being shut down). In such a case, the container calls the destroy() method of the Servlet interface. In this method, you release any resources the servlet is using and save any persistent state. The \u00a0destroy \u00a0method releases any resources which it has acquired \u00a0during initialization using \u00a0the init method.<\/p>\r\n \r\n

          The web container normally tries to ensure that there is no client request processing in progress before before calling the destroy method.The server tries to ensure this by calling the destroy method only after all service requests have returned or after a server-specific grace period, whichever comes first. If your servlet has operations that may run longer than the server\u2019s grace period, the operations could still be running when destroy() is called.<\/p>\r\n \r\n

          Summary :<\/strong><\/p>\r\n \r\n

          So in the life cycle of an Servlet. init is the first method which will be invoked when the application starts, this will be followed by service method being invoked whenever a client requests, and then when the application stops the destroy method is invoked.<\/p>\r\n\r\n\r\n\r\n
          you can view video on The Servlet Life Cycle<\/strong><\/td>\r\n\"\"<\/a><\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n
          Suggested Reading:<\/strong><\/div>\r\n
            \r\n \t
          1. Core Servlets and Java Server Pages Volume 1 by Marty Hall & Larry Brown, Second Edition, Pearson Education.<\/li>\r\n \t
          2. Inside Servlets by Dustin R Callaway, Pearson Education.<\/li>\r\n \t
          3. Java Server Programming for Professionals by Ivan Bayross, Sharanam Shah, Cynhthia Bayross and Vaishali Shah Shroff Publishers and Distributros.<\/li>\r\n \t
          4. http:\/\/download.oracle.com\/otndocs\/jcp\/servlet-3.0-fr-oth-JSpec\/<\/li>\r\n<\/ol>","rendered":"
            \"epgp<\/a>
            \n<\/span><\/div>\n

             <\/p>\n

            What is a servlet?<\/strong><\/p>\n

             <\/p>\n

            Servlet is a server side component which receives a request from a client, processes the request and sends a content based response back to the client. The Servlet is a separate API, it is not part of the standard Java API. The Servlet as it runs on the server side, is embedded inside a Server. Most commonly the servlets are used for HTTP protocol, and \u00a0are \u00a0embedded \u00a0inside \u00a0a WebContainer. Common implementations of the Servlet specifications are Glassfish, Tomcat, jRun, jBoss, Jetty, etc.. Tomcat used to be the reference implementation for the servlet specifications, since Servlet specifications 3.0, Glassfish is the reference implementation. The Servlet specifications are managed independent of the standard Java specifications. There was a major standardization in the Servlet specifications version 2.0. It standardized the directory structure for deployment of the Servlet and related components, and introduced the concept of a web application. current specification is version 3.0.<\/p>\n

             <\/p>\n

            The Servlet specification is designed in generic way for any server which uses request response based protocol. There are 2 packages in the servlet API<\/p>\n

              \n
            1. javax.servlet, which is generic, and<\/li>\n
            2. javax.servlet.http, which is an extension of the generic APIs in the javax.servlet, and specific to HTTP protocol.<\/li>\n<\/ol>\n

               <\/p>\n

              Servlet specifications mandate the implementations to support HTTP protocol. An implementation can also support other protocols, e.g., there are implementations which also support the \u00a0SIP protocol.<\/p>\n

               <\/p>\n

              So in general a servlet is a component which is embedded inside some ServletContainer This is something similar to an Applet being embedded inside a Browser. which is a container for the Applet.<\/p>\n

               <\/p>\n

              Number of servlets can be configured in a single web application. In turn several web applications may be deployed on a single instance of a WebContainer.<\/p>\n

               <\/p>\n

              Architecture Diagram:<\/strong><\/p>\n

              \"\"<\/p>\n

              \n

               <\/p>\n

              The life-cycle of a Servlet is controlled by the container in which the Servlet has been configured as part of a deployed web application.<\/p>\n

               <\/p>\n

              The configuration of a web application maps URL patterns to Servlets.<\/p>\n

               <\/p>\n

              When a ServletContainer starts, it would first look for all the deployed web applications. Then it would create an instance of ServletContext corresponding to each web application, similar to an AppletContext being created for each html page containing any applet tag inside a browser.<\/p>\n

               <\/p>\n

              It would then find out the Servlets which are configured in web application. A Servlet may \u00a0be configured to be loaded at the \u00a0startup \u00a0of \u00a0web \u00a0application. \u00a0For \u00a0each \u00a0servlet \u00a0configured \u00a0to \u00a0be loaded on startup, it\u00a0 would create an instance of ServletConfig, similar to an AppletStub being created for each Applet in the html page inside a browser. These Servlet instances \u00a0are \u00a0then initialized by invoking init() method and passing corresponding ServletConfig instance.<\/p>\n

               <\/p>\n

              When a request arrives from a client, based on the URL, Servlet would \u00a0be \u00a0identified \u00a0and \u00a0the following steps would be performed on the identified Servlet :<\/span><\/p>\n<\/div>\n

                \n
              1. If an instance of the Servlet does not exist, the web container (this may happen for Servlets which are not configure to load at startup) :\n
                  \n
                1. Loads the Servlet class.<\/li>\n
                2. Creates an instance of the Servlet class.<\/li>\n
                3. Creates an instance of ServletConfig based on configuration information related to this Servlet.<\/li>\n
                4. Initializes the Servlet instance by calling the init() method. The aforesaid ServletConfig instance is passed to init() method.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
                    \n
                  1. Invokes the service method, passing request and response objects.<\/li>\n
                  2. If it needs to take the servlet out of service, the container finalizes the servlet by calling the Servlet\u2019s destroy() method.<\/li>\n<\/ol>\n
                    \n

                    Creating and Initializing a Servlet<\/strong><\/p>\n

                     <\/p>\n

                    The web container initializes a servlet after loading and instantiating the servlet class and before delivering requests from clients. To customize this process to allow the servlet to read persistent configuration data, initialize resources, and perform any other one-time activities. If it cannot complete its initialization process, a servlet throws an UnavailableException.<\/p>\n

                     <\/p>\n

                    A Servlet can be configured with initialization parameters which are made available to the Servlet through ServletConfig object. Initialization parameter can be\u00a0 used to provide data needed by a particular servlet..<\/p>\n

                     <\/p>\n

                    Web container would create instance of the deployed Servlet using its default constructor. Next it would invoke the first method on the instance of Servlet. This method is the init() method. similar to the<\/p>\n

                     <\/p>\n

                    void setStub(AppletStub stub)<\/p>\n

                    of the Applet.<\/p>\n

                    Here the init() method also has a parameter which is the ServletConfig.<\/p>\n

                     <\/p>\n

                    void init(ServletConfig cfg) throws ServletException<\/p>\n

                    So the first life cycle method of a Servlet is init. Servlet<\/span><\/p>\n<\/div>\n

                    In case the init() method invocation on a Servlet fails by throwing a ServletException, the \u00a0web container would take the Servlet out of service. The init() method may also fail by throwing UnavailableException ( sub-class of ServletException). The UnavailableException may indicate a duration for unavailability. In such case, the web container may recreate Servlet and try initialization again after the specified duration.<\/p>\n

                     <\/p>\n

                    Request Processing<\/strong><\/p>\n

                     <\/p>\n

                    The request processing for a servlet is handled by its service method. The term service method is used for any method in a servlet class that provides a service to a client.<\/span><\/p>\n

                     <\/p>\n

                    After startup of web container is completed, it becomes ready to accept requests from client and give response back to the client. When a request arrives from the client, the web container first identifies the servlet for which this request has arrived based on URL. It would then encapsulate information available in the client request in an instance of ServletRequest. It would also allocate a Buffer and encapsulate it in an instance of ServletResponse. This Buffer is to be used by the Servlet to write the content which it wants to send back to the client. After creating the instance of ServletRequest and ServletResponse, it now invokes the service method on the instance of Servlet.<\/span><\/p>\n

                     <\/p>\n

                    void service(ServletRequest request, ServletResponse response) throws ServletException, IOException<\/span><\/p>\n

                     <\/p>\n

                    So the implementation of the service method by the Servlet is supposed to look at the information in the ServletRequest object, do some processing and then setup a response content in the buffer of the ServletResponse object. Once the service method is over, web container sends the content available in the buffer according to the protocol.<\/span><\/p>\n

                     <\/p>\n

                    In case the service() method invocation on a Servlet fails by throwing a ServletException, the web container would first invoke destroy() on the Servlet and then takes it out of service. The service() method may also fail by throwing UnavailableException ( sub-class of ServletException). Here also the web container would first invoke destroy() on the Servlet and then takes it out of service. The UnavailableException may indicate a duration for unavailability. In such case, the\u00a0 web container may recreate Servlet and try initialization again after \u00a0the \u00a0specified \u00a0duration \u00a0to \u00a0bring \u00a0it \u00a0back \u00a0to ready for request processing.<\/span><\/p>\n

                     <\/p>\n

                    If any request is received by web container for the Servlet which is out of service, web container\u00a0<\/span>directly gives appropriate negative response to the client without trying to invoke the service()\u00a0<\/span>method.<\/span><\/p>\n

                     <\/p>\n

                    Finalizing a Servlet<\/strong><\/p>\n

                     <\/p>\n

                    All web containers (Servlet containers) provide administrative tools to manage the deployment and other activities related to web application such as start, stop, undeploy etc. When an application is stopped or restarted, then the Servlet Container would destroy all the Servlet instances created for that application. The Servlet Container invokes the destroy() method before it destroys the Servlet instance.<\/p>\n

                     <\/p>\n

                    Whenever the web container determines that a servlet should be removed from \u00a0service \u00a0(for example, when a container wants to reclaim memory resources or when it is being shut down). In such a case, the container calls the destroy() method of the Servlet interface. In this method, you release any resources the servlet is using and save any persistent state. The \u00a0destroy \u00a0method releases any resources which it has acquired \u00a0during initialization using \u00a0the init method.<\/p>\n

                     <\/p>\n

                    The web container normally tries to ensure that there is no client request processing in progress before before calling the destroy method.The server tries to ensure this by calling the destroy method only after all service requests have returned or after a server-specific grace period, whichever comes first. If your servlet has operations that may run longer than the server\u2019s grace period, the operations could still be running when destroy() is called.<\/p>\n

                     <\/p>\n

                    Summary :<\/strong><\/p>\n

                     <\/p>\n

                    So in the life cycle of an Servlet. init is the first method which will be invoked when the application starts, this will be followed by service method being invoked whenever a client requests, and then when the application stops the destroy method is invoked.<\/p>\n\n\n\n
                    you can view video on The Servlet Life Cycle<\/strong><\/td>\n\"\"<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
                    Suggested Reading:<\/strong><\/div>\n
                      \n
                    1. Core Servlets and Java Server Pages Volume 1 by Marty Hall & Larry Brown, Second Edition, Pearson Education.<\/li>\n
                    2. Inside Servlets by Dustin R Callaway, Pearson Education.<\/li>\n
                    3. Java Server Programming for Professionals by Ivan Bayross, Sharanam Shah, Cynhthia Bayross and Vaishali Shah Shroff Publishers and Distributros.<\/li>\n
                    4. http:\/\/download.oracle.com\/otndocs\/jcp\/servlet-3.0-fr-oth-JSpec\/<\/li>\n<\/ol>\n","protected":false},"author":4,"menu_order":16,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":["mr-pravin-jain"],"pb_section_license":""},"chapter-type":[],"contributor":[58],"license":[],"class_list":["post-101","chapter","type-chapter","status-publish","hentry","contributor-mr-pravin-jain"],"part":3,"_links":{"self":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/chapters\/101","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/wp\/v2\/users\/4"}],"version-history":[{"count":9,"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/chapters\/101\/revisions"}],"predecessor-version":[{"id":404,"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/chapters\/101\/revisions\/404"}],"part":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/parts\/3"}],"metadata":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/chapters\/101\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/wp\/v2\/media?parent=101"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/pressbooks\/v2\/chapter-type?post=101"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/wp\/v2\/contributor?post=101"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/itp16\/wp-json\/wp\/v2\/license?post=101"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}