- Servlet class loading
- Servlet Instantiation
- call the init method
- call the service method
- call destroy method
The Sequence –
The actual sequence of events in the servlet lifecycle is as given in the objective, i.e. load, instantiate,init,service and eventually destroy.
Class loading and instantiation
If you consider a servlet to be just like any other Java program, except that it runs within a servlet container, there has to be a process of loading the class and making it ready for requests. Servlets do not have the exact equivalent of a main method that causes them to start execution.
When a web container starts it searches for the deployment descriptor (WEB.XML) for each of its web applications. When it finds a servlet in the descriptor it will create an instance of the servlet class. At this point the class is considered to be loaded (but not initialized).
The init method
The HttpServlet class inherits the init method from GenericServlet. The init method performs a role slightly similar to a constructor in an “ordinary” Java program in that it allows initialization of an instance at start up. It is called automatically by the servlet container and as it causes the application context (WEB.XML) to be parsed and any initialization will be performed. It comes in two versions, one with a zero parameter constructor and one that takes a ServletConfig parameter.
The init method is only called once when a servlet is first loaded.
Once the init method returns the servlet is said to be placed into service. The process of using init to initialize servlets means that it is possible to change configuration details by modifying the deployment descriptor without having them hard coded in with your Java source and needing a re-compilation. Examples of configuration details could be locale, language, time zone, database driver and just about any other modifiable parameter you can think of. As it only makes sense to initialize a servlet once the specification ensures that init will only be called once. This means that simply changing the values in the deployment descriptor will not magically cause running servlets to pick up the change values. One (rather drastic) way to ensure that the changed deployment descriptor values are picked up is to restart the server.
Forcing initialization
By default servlets are initialized the first time they are called, which is sometimes called “lazy loading” as it puts off initialization to the last possible moment. This brings a performance benefit in terms of starting the container, but it can mean that the first client that makes a request will experience what seems like poor performance. To get around this a deployment descriptor can include a tag which will force initialization when the servlet is loaded. This is sometimes called pre-loading or pre-initializing a servlet.
Calling the service method
The code that makes a servlet “go” is the. servlet
service(ServletRequest,ServletResponse)
method which you have seen in previous examples. The service method is called by the container and the defaultimplementation inspects the request to see what should be done.
The service method is called for each request processed and is not normally overridden by the programmer.
By default it will dispatch the request to the appropriate method, typically a programmer overloaded version of the helper methods doGet or doPost. There is generally no good reason to override the service method, but if you did, you would have to write code to delegate to the helper meethods or call super.service(). On balance, don’t override service().
The destroy Method
Two typical reasons for the destroy method being called are if the container is shutting down or if the container is low on resources. This can happen when the container keeps a pool of instances of servlets to ensure adequate performance. If no requests have come in for a particular servlet for a while it may destroy it to ensure resources are available for the servlets that are being requested.
The destroy method is called only once, before a servlet is unloaded and thus you cannot be certain when and if it is called.
The destroy method should contain any code required for “cleaning up” resources that were obtained in the init method, such as opening files or loading database drivers. Once the destroy method has been called that instance of the servlet effectively ceases to exist from a productivity point of view. The init or service methods cannot be called again and the only thing that can happen from then on is that the instance gets unloaded. Unloading happens when an instance is garbage collected. This follows the usual rules of Java garbage collection in that you can never be sure when it will happen and just because an instance is eligible for garbage is no guarantee that it actually will happen.
- Salesforce Certified Platform Developer I – Winter ’18 Release Exam - November 23, 2017
- Salesforce Certified Platform App Builder – Winter ’18 Release Exam - November 22, 2017
- Salesforce Certified Administrator – Winter’ 18 Release Exam - November 21, 2017
