Executive in wait

Application Lifecycle Events August 16, 2005

• The application events facility gives the Web Application Developer greater control over the lifecycle of the ServletContext and HttpSession and ServletRequest , allows for better code factorization, and increases efficiency in managing the resources that the Web application uses.
• Application event listeners are classes that implement one or more of the servlet event listener interfaces.
• They are instantiated and registered in the Web container at
  the time of the deployment of the Web application. They are provided by the Developer in the WAR.
• Servlet event listeners support event notifications for state changes in the
  ServletContext , HttpSession and ServletRequest objects.
• Servlet context listeners are used to manage resources or state held at a JVM level for the application.
• HTTP session listeners are used to manage state or resources associated with a series of requests made into a Web application from the same
  client or user.
• Servlet request listeners are used to manage state across the lifecycle of servlet requests.

• Event Type	Description	Listener Interface
  Servlet Context Events
  Lifecycle	The servlet context has just been created and is available to service its first request, or the servlet context is about to be shut down.	javax.servlet.ServletContextListener
  Changes to attributes	Attributes on the servlet context have beenadded, removed, or replaced.	javax.servlet.ServletContextAttributeListener
  HTTP Session Events
  Lifecycle	An HttpSession has been created, invalidated,or timed out.	javax.servlet.http.HttpSessionListener
  Changes to attributes	Attributes have been added, removed, or replaced on an HttpSession .	javax.servlet.HttpSessionAttributeListener
  Session migration	HttpSession has been activated or passivated.	javax.servlet.HttpSessionActivationListener
  Object binding	Object has been bound to or unbound from Httpsession	javax.servlet.HttpSessionBindingListener

An Example of Listener Use:

1. When the application starts up, the listener class is notified. The application logs on to the database, and stores the connection in the servlet context.
2. Servlets in the application access the connection as needed during activity in the Web application.
3. When the Web server is shut down, or the application is removed from the Web server, the listener class is notified and the database connection is closed.

Listener Class Configuration

• The Developer of the Web application provides listener classes implementing one or more of the listener classes in the javax.servlet API.
• Each listener class must have a public constructor taking no arguments.
• Listener classes are declared in the Web application deployment descriptor using the listener element. They are listed by class name in the order in which they are to be invoked.
• The Web container creates an instance of each listener class and registers it for event notifications prior to the processing of the first request by the application.
• During Web application execution, listeners are invoked in the order of their registration.
• On application shutdown, listeners are notified in reverse order to their declarations with notifications to session listeners preceeding notifications to context listeners. Session listeners must be notified of session invalidations prior to context listeners being notified of application shutdown.
• The following example is the deployment grammar for registering two servlet context lifecycle listeners and an HttpSession listener.
  Suppose that com.acme.MyConnectionManager and com.acme.
  MyLoggingModule both implement javax.servlet.ServletContextListener , and that com.acme.MyLoggingModule additionally implements
  javax.servlet.HttpSessionListener. Also, the Developer wants
  com.acme.MyConnectionManager to be notified of servlet context lifecycle events before com.acme.MyLoggingModule. Here is the deployment descriptor for this application:
  <web-app>

  <display-name>MyListeningApplication</display-name>

  <listener>

  <listener-class>com.acme.MyConnectionManager</listener-

  class>

  </listener>

  <listener>

  <listener-class>com.acme.MyLoggingModule</listener-class>

  </listener>

  <servlet>

  <display-name>RegistrationServlet</display-name>

  …etc

  </servlet>

  </web-app>

• The container is required to complete instantiation of the listener classes in a Web application prior to the start of execution of the first request into the application.
• The container must maintain a reference to each listener instance until the last request is serviced for the Web application.
• Application code inside a listener may throw an exception during operation.
• The container must allow unhandled exceptions to be handled by the error page mechanism
• In distributed Web containers, HttpSession instances are scoped to the particular JVM servicing session requests, and the ServletContext object is scoped to the Web container’s JVM.
• Listener classes provide the Developer with a way of tracking sessions within a Web application. It is often useful in tracking sessions to know whether a session became invalid because the container timed out the session, or because a Web component within the application called the invalidate method.

Web Applications in Java August 16, 2005

• A Web application is a collection of servlets, HTML pages, classes, and other resources that make up a complete application on a Web server.
• By default, an instance of a Web application must run on one VM at any one time. This behavior can be overridden if the application is marked as
  “distributable” via its deployment descriptor. An application marked as
  distributable must obey a more restrictive set of rules than is required of a normal Web application.
• The servlet container must enforce a one to one correspondence between a Web application and a ServletContext.A ServletContext object provides a servlet with its view of the application.
• A Web application may consist of the following items:
  • Servlets
  • JSP Pages
  • Utility Classes
  • Static documents (HTML, images, sounds, etc.)
  • Client side Java applets, beans, and classes
  • Descriptive meta information that ties all of the above elements together
• A Web application exists as a structured hierarchy of directories.
• The root of this hierarchy serves as the document root for files that are part of the application.
• For example, for a Web application with the context path /catalog in a Web container, the index.html file at the base of the Web application hierarchy can be served to satisfy a request from /catalog/index.html
• Web containers must reject Web applications defining a context path could cause potential conflicts in this URL namespace. This may occur,
  for example, by attempting to deploy a second Web application with the same context path.
• Requests are matched to resources in a case-sensitive manner
• A special directory exists within the application hierarchy named “WEB-INF “. This directory contains all things related to the application that aren’t in the document root of the application.
• The WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may
  be served directly to a client by the container.Any requests from the client to access the resources in WEB-INF/directory must be returned with a SC_NOT_FOUND (404) response.
• The contents of the WEB-INF directory are visible to servlet code using the getResource and getResourceAsStream method calls on the ServletContext
• If the Application Developer needs access, from servlet code, to application specific configuration information that he does not wish to be exposed directly to the Web client, he may place it under this directory.
• The contents of the WEB-INF directory are:
  • The /WEB-INF/web.xml deployment descriptor.
  • The /WEB-INF/classes/directory for servlet and utility classes. The classes in this directory must be available to the application class loader.
  • The /WEB-INF/lib/*.jar area for Java ARchive files. These files contain servlets, beans, and other utility classes useful to the Web application. The Web application class loader must be able to load classes from any of these archive files.
• The Web application class loader must load classes from the WEB-INF/classes directory first, and then from library JARs in the WEB-INF/lib directory.
• The following is a listing of all the files in a sample Web application:
  /index.html
  /howto.jsp
  /feedback.jsp
  /images/banner.gif
  /images/jumping.gif
  /WEB-INF/web.xml
  /WEB-INF/lib/jspbean.jar
  /WEB-INF/classes/com/mycorp/servlets/MyServlet.class
  /WEB-INF/classes/com/mycorp/util/MyUtils.class
• Web applications can be packaged and signed into a Web ARchive format (WAR) file using the standard Java archive tools.
• The Web application deployment descriptor includes the following types of configuration and deployment information:
  • ServletContext Init Parameters
  • Session Configuration
  • Servlet/JSP Definitions
  • Servlet/JSP Mappings
  • MIME Type Mappings
  • Welcome File list
  • Error Pages
  • Security
• When a number of applications make use of the same code or resources, they will typically be installed as library files in the container. These files are often common or standard APIs that can be used without sacrificing portability.
• Files used only by one or a few applications will be made available for access as part of the Web application. The container must provide a directory for these libraries.
• E:g In tomcat, for classes and resources that must be shared across all web applications, place unpacked classes and resources under $CATALINA_BASE/shared/classes, or place JAR files containing those classes and resources under $CATALINA_BASE/shared/lib. $CATALINA_HOME/common/classes contains additional classes that are made visible to both Tomcat internal classes and to all web applications
• The application developer depending on such an extension or extensions must provide a META-INF/MANIFEST.MF entry in the WAR file listing all extensions needed by the WAR.
• The class loader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal J2SE semantics using getResource
• A server should be able to replace an application with a new version without restarting the container. When an application is replaced, the container should provide a robust method for preserving session data within that application.
• To allow developers to customize the appearance of content returned to a Web client when a servlet generates an error, the deployment descriptor defines a list of error page descriptions.
• The syntax allows the configuration of resources to be returned
  by the container either when a servlet or filter calls sendError on the response for specific status codes, or if the servlet generates an exception or error that propagates to the container.
• If the sendError method is called on the response, the container consults the list of error page declarations for the Web application that use the status-code syntax and attempts a match. If there is a match, the container returns the resource as indicated by the location entry.
• A servlet or filter may throw the following exceptions during processing of a request:
  • runtime exceptions or errors
  • ServletExceptions or subclasses thereof
  • IOExceptions or subclasses thereof
• The Web application may have declared error pages using the exception-
  type element. In this case the container matches the exception type by comparing the exception thrown with the list of error-page definitions that use the exception-type element.
• Error-page declarations using the exception-type element in the deployment descriptor must be unique up to the class name of the exception-type.Same goes with error-page declarations using the status-code element.
• If a servlet generates an error that is not handled by the error page mechanism as described above, the container must ensure to send a response with status 500.
• Web Application developers can define an ordered list of partial URIs called welcome files in the Web application deployment descriptor.
• If a Web container receives a valid partial request, the Web container must examine the welcome file list defined in the deployment descriptor.
• If no matching welcome file is found in the manner described, the container may handle the request in a manner it finds suitable. For some configurations this may mean returning a directory listing or for others returning a 404 response.
• Provision has been made in the Web application deployment descriptor for specifying information allowing a servlet to obtain references to resources and enterprise beans. The deployment elements that contain this information are:
  • env-entry
  • ejb-ref
  • ejb-local-ref
  • resource-ref
  • resource-env-ref
• The developer uses these elements to describe certain objects that the Web application requires to be registered in the JNDI namespace in the Web container at runtime.
• Servlet containers that are part of a J2EE technology-compliant implementation are required to support this syntax.
• When a web application is deployed into a container, the following steps must be performed, in this order, before the web application begins processing client requests.
  • Instantiate an instance of each event listener identified by a
  <listener> element in the deployment descriptor.
  • For instantiated listener instances that implement ServletContextListener , call the contextInitialized() method.
  • Instantiate an instance of each filter identified by a
  <filter>element in the deployment descriptor and call each filter instance’s init()method.
  • Instantiate an instance of each servlet identified by a
  <servlet>element that includes a
  <load-on-startup> element in the order defined by the load-on-startup element values, and call each servlet instance’s init()method.