JSP page life-cycle phases

JSP page life-cycle phases
Phase Name	Description
Page translation	The page is parsed and a Java file containing the corresponding servlet is created.
Page compilation	The Java file is compiled.
Load class	The compiled class is loaded.
Create instance	An instance of the servlet is created.
Call jspInit()	This method is called before any other method to allow initialization.
Call _jspService()	This method is called for each request.
Call jspDestroy()	This method is called when the servlet container decides to take the servlet out of service.

Servlet Life Cycle

1. Loading and instantiating a servlet

When we start up a servlet container, it looks for deployment descriptors (web.xml) which includes an entry for each of the servlets it uses. An entry specifies the name of the servlet and a Java class name for the servlet. The servlet container creates an instance of the given servlet class using the method Class.forName(className).newInstance().


2. Initializing a servlet

Once the container creates the servlet instance, it calls the init(ServletConfig) method on this newly created instance. The ServletConfig object contains all the initialization parameters that we specify in the deployment
descriptor of the web application. The framework guarantees that the servlet container will call the init() method once and only once on a servlet instance.

3. Servicing client requests

After the servlet instance is properly initialized, it is ready to service client requests. When the servlet container receives requests for this servlet, it will dispatch them to the servlet instance by calling the Servlet.service(ServletRequest, ServletResponse) method.

4. Destroying a servlet

If the servlet container decides that it no longer needs a servlet instance, it calls the destroy() method on the servlet instance. Once this method is called, the servlet instance will be out of service and the container will never call the service() method on this instance. The servlet container cannot reuse this instance in any way. From this state, a servlet instance may only go to the unloaded state. Before calling the destroy() method, the servlet
container waits for the remaining threads that are executing the servlet’s service() method to finish.

A servlet container may destroy a servlet if it is running low on resources and no request has arrived for a servlet in a long time. Similarly, if the servlet container maintains a pool of servlet instances, it may create and destroy the instances from time to time as required. A servlet container may also destroy a servlet if it is shutting down.

5. Unloading a servlet

Once destroyed, the servlet instance may be garbage collected, in which case the servlet instance is said to be unloaded. If the servlet has been destroyed because the servlet container is shutting down, the servlet class will also be unloaded.


Conclusion 
Before a servlet can service the client requests, a servlet container must take certain steps in order to bring the servlet to a state in which it is ready to service the requests. The first step is loading and instantiating the servlet class; the servlet is now considered to be in the loaded state. The second step is initializing the servlet instance. Once the servlet is in the initialized state, the container can invoke its service() method whenever it receives a request from the client. There may be times when the container will call the destroy() method on the servlet instance to put it in the destroyed state. Finally, when the servlet container shuts down, it must unload the servlet instance.

Preinitializing a servlet

Usually, a servlet container does not initialize the servlets as soon as it starts up. It initializes a servlet when it receives a request for that servlet for the first time. This is called lazy loading. Although this process greatly improves the startup time of the servlet container, it has a drawback.

If the servlet performs many tasks at the time of initialization, such as caching static data from a database on initialization, the client that sends the first request will have a poor response time.

In many cases, this is unacceptable. The servlet specification defines the <load-on-startup> element, which can be specified in the deployment descriptor (web.xml) to make the servlet container load and initialize the servlet as soon as it starts up.

This process of loading a servlet before any request comes in is called preloading, or preinitializing, a servlet.

Download free SCJP 1.5 Kathy Sierra and SCWCD Exam study kit

SCJP

Sun Certified Programmer for Java 5

Free Download

SCJP

Exam Study Guide

Author :

Kathy sierra

SCWCD

Exam Study Kit

Second Edition

Free Download

JAVA web component developer certification

Author :

Hanumant Deshmukh

Jignesh Malavia

Matthew Scarpino

Java : Assertions

Working with the Assertion Mechanism


Suppose you assume that a number passed into a method (say, methodA()) will never be negative. While testing and debugging, you want to validate your assumption, but you don't want to have to strip out print statements, runtime exception handlers, or if/else tests when you're done with development. But leaving any of those in is, at the least, a performance hit. Assertions to the rescue!


Check out the following code:

private void methodA(int num) {
if (num >= 0) {
useNum(num + x);
} else { 
// num must be < 0
// This code should never be reached!
System.out.println("oops! num is a negative number! " + num);
}
}


Because you're so certain of your assumption, you don't want to take the time (or program performance hit) to write exception-handling code. And at runtime, you don't want the if/else either because if you do reach the else condition, it means your earlier logic (whatever was running prior to this method being called) is flawed. Assertions let you test your assumptions during development, but the assertion code basically evaporates when the program is deployed, leaving behind no overhead or debugging code to track down and remove. Let's rewrite methodA() to validate that the argument was not negative:



private void methodA(int num) {


assert (num>=0); // throws an AssertionError
// if this test isn't true
useNum(num + x);
}




Not only do assertions let your code stay cleaner and tighter, but because assertions are inactive unless specifically "turned on" (enabled), the code will run as though it were written like this:



private void methodA(int num) {
useNum(num + x); // we've tested this;
// we now know we're good here
}



Assertions work quite simply. You always assert that something is true. If it is, no problem. Code keeps running. But if your assertion turns out to be wrong (false), then a stop-the-world AssertionError is thrown (that you should never, ever handle!) right then and there, so you can fix whatever logic flaw led to the problem. Assertions come in two flavors: really simple and simple, as follows:


Really simple:


private void doStuff() {
assert (y > x);
// more code assuming y is greater than x
}

Simple:

private void doStuff() {
assert (y > x): "y is " + y + " x is " + x;
// more code assuming y is greater than x
}

The difference between the two is that the simple version adds a second expression, separated from the first (boolean expression) by a colon, this expression's string value is added to the stack trace. Both versions throw an immediate AssertionError, but the simple version gives you a little more debugging help while the really simple version simply tells you only that your assumption was false.


Running with Assertions

Here's where it gets cool. Once you've written your assertion-aware code (in other words, code that uses assert as a keyword, to actually perform assertions at runtime), you can choose to enable or disable your assertions at runtime! Remember, assertions are disabled by default.

Enabling Assertions at Runtime

You enable assertions at runtime with

java -ea com.TestAssertions
or
java -enableassertions com.geeksanonymous.TestClass

The preceding command-line switches tell the JVM to run with assertions enabled.




Disabling Assertions at Runtime

You must also know the command-line switches for disabling assertions,

java -da com.TestAssertions
or
java -disableassertions com.TestAssertions

Because assertions are disabled by default, using the disable switches might seem unnecessary. Indeed, using the switches the way we do in the preceding example just gives you the default behavior (in other words, you get the same result regardless of whether you use the disabling switches). But…you can also selectively enable and disable assertions in such a way that they're enabled for some classes and/or packages, and disabled for others, while a particular program is running.



Example


/* TestAssertions.java */
public class  TestAssertions
{
public static void acceptsEvenNumber(int num)
{
if(num %2 != 0)
{
System.out.println("Please enable Assertion");
}
System.out.println("It is Even number : "+num);
}


public static void main(String[] args) 
{
//int num = 10;
int num = 11;
assert(num %2 == 0);// throws an AssertionError
// if this test isn't true


acceptsEvenNumber(num);
}
}


Output



C:\Java>java TestAssertions
Please enable Assertion
It is Even number : 11


C:\Java>java -ea TestAssertions
Exception in thread "main" java.lang.AssertionError
        at TestAssertions.main(TestAssertions.java:18)