message = qSession.createMapMessage(); message.setString("name", firstName + " " + lastName); message.setString("cruise", cruise); qSender.send(message); qConn.close(); System.out.println("TravelAgentBean: Cruise reservation sent"); } catch (Exception e) { System.err.println("TravelAgentBean: Error on sending message " + e); } } Servlet filters Servlet filters are pluggable Web components that allow us to implement pre-processing and post-processing logic in our Web applications. Filters support the basic request processing facilities of servlets and JSP pages, such as:
Servlet filters are small Web components that intercept requests and responses to view, extract, or in some way manipulate the data that is being exchanged between client and server. Filters are Web components that typically encapsulate some functionality that, while important, is not central to processing the client request or sending a response. Typical examples include logging data about the request or response, processing security protocols, managing session attributes, and more. Filters provide a modular, object-oriented mechanism for encapsulating common tasks into pluggable components that are declared via a configuration file and processed dynamically. Many elements combine in Servlet filters to make them unique, powerful, and modular Web components. Namely, Servlet filters are:
Servlet filters are modular, reusable components that are flexibly declared via a configuration file. Filters process incoming requests and outgoing responses dynamically and can be transparently added and removed without modifying application code. Finally, filters are independent of any platform or Servlet container, allowing them to be easily deployed in any compliant J2EE environment. The Servlet filter architecture The application developer creates a filter by implementing the javax.servlet.Filter interface and providing a public constructor taking no arguments. The class is packaged in the Web Archive along with the static content and servlets that make up the Web application. A filter is declared using the <filter> element in the deployment descriptor. A filter or collection of filters can be configured for invocation by defining <filter-mapping> elements in the deployment descriptor. This is done by mapping filters to a particular servlet by the servlet's logical name, or mapping to a group of servlets and static content resources by mapping a filter to a URL pattern. As the name suggests, a Servlet filter is used to intercept an incoming request and/or outgoing response, and monitor, modify, or in some way process the stream of data that is passing through. Filters are self-contained, modular components that can be added to a request/response chain, or removed without affecting the other Web components in the application. Filters simply alter the runtime processing of requests and responses, and thus should not be tied directly into the Web application framework, except through well-defined standard interfaces within the Servlet API. A Web resource can be configured to have no filters associated with it (default), a single filter (typical), or even a chain of filters. Like a servlet, a filter receives a request and response object. The filter will then inspect the request object and decide to forward the request to the next component in the chain, or stop the request and send a response directly back to the client. If the request is forwarded, it is passed to the next resource in the chain (another filter, a servlet, or a JSP page). After the request works its way through the chain and is processed by the server, a response is sent back through the chain in reverse order. This gives each filter an opportunity to handle the response object if necessary. The order the container uses in building the chain of filters to be applied for a particular request URI is as follows:
Creating a new filter class 0 The Filter wizard enables you to create Java filter classes for various J2EE filter types, such as authentication filters, encryption filters, and data compression filters. To create a filter class, do the following:
The filter that you requested is generated and added to the Java package that you designated under the Java source folder: Implementing a Servlet filter 7 First, you program the filter implementation class, second add the filter to your Web application (by declaring it within the Web deployment descriptor - web.xml), and, finally, package the application with the filter and deploy it.
When you test your web application, the filter will track the approximate length of time taken to fulfill a client's Web request: 2
[17.08.05 16:26:46:656 EEST] 49a565a SystemOut O LoggingFilter: request to : /ReservationController took 0.109 seconds The many uses of filters Anywhere that a decorating filter pattern or interceptor pattern would be appropriate, you can use a filter. Some of the most common uses for filters are as follows:
Fitting filters into an MVC architecture The Model-View-Controller (MVC) architecture is an effective design that has now been incorporated as the overriding design methodology within the most popular Web application frameworks. Filters serve to augment the request/response processing flow of an MVC architecture. Whether the request/response is between the client and server or between other components on the server, the application of filters in the process flow is the same. From an MVC perspective, the dispatcher component (which is either included in or works in conjunction with the Controller component) forwards requests to the appropriate application component for processing. This makes the Controller layer the optimum location for including Servlet filters. Filters can be applied to all requests by placing them in front of the Controller component itself, or applied to individual Web components by placing it between the controller/dispatcher and the Model and View components. 5 Servlet Life-cycle Listener The Java Servlet 2.3 specification provides mechanisms for notifying application code about events in the Web application life cycle. Life cycle events include creation and destruction of a servlet context or an HTTP session, and creation, modification, or removal of servlet context attributes and HTTP session attributes. Furthermore, any object may be notified when it is bound to or unbound from an HTTP session attribute. Application life cycle listeners are often used to provide consistent, managed access to other resources. For example, consider a set of servlets within the same Web application that share a database connection on a single server. To improve performance, some servlets save a database connection as a servlet context attribute, and reuse it across multiple servlet service invocations for multiple clients. When the application is shut down, the database connection should be closed. To manage the database connection, an application developer creates a servlet context event listener. The listener class opens the database and initializes a context attribute with a reference when the application is deployed. The listener class also closes the database when the application is undeployed. 6 To create a life cycle listener, an application developer writes classes that implement listener interfaces for life cycle events, and the deployer configures these classes to be used by a Web application. The class files for the listeners are packaged in the Web archive, and configured using the deployment descriptor web.xml. A listener class must have a public constructor with no arguments. Each Web application can have multiple listeners of each type. The interfaces provided for listening to Web application life cycle events are:
Creating a new listener class The Life-cycle Listener wizard enables you to create Java listener classes for various J2EE listener types related to servlet context and session events and attributes 1 To create a listener class, do the following:
The listener class that you requested is generated and added to the Java package that you designated under the Java source folder. The sample code defines listeners for two types of events: servlet context creation/destruction, session creation/destruction. Each method simply prints its name to standard output, to indicate that the callback to the method occurred. The callbacks print feedback to the server process's standard output unit.
public void contextInitialized(ServletContextEvent arg0) { System.out.println("TitanListener: contextInitialized"); } public void contextDestroyed(ServletContextEvent arg0) { System.out.println("TitanListener: contextDestroyed"); } public void sessionCreated(HttpSessionEvent arg0) { System.out.println("TitanListener: sessionCreated"); } public void sessionDestroyed(HttpSessionEvent arg0) { System.out.println("TitanListener: sessionDestroyed"); } Configuring Listener Classes 6 Listener classes are declared using the <listener> tag in the deployment descriptor file, web.xml:
<listener> <listener-class>com.titan.listeners.TitanListener</listener-class> </listener> The Web container is responsible for creating and providing callbacks to instances of the listener classes. You will see the output from listener classes in server's console when you start web application and invoke any servlet or JSP participating in HTTP session: 7
[17.08.05 16:28:37:606 EEST] 3dfe181b WebContainer A SRVE0169I: Loading Web Module: titan-web. [17.08.05 16:28:37:653 EEST] 3dfe181b SystemOut O TitanListener: contextInitialized ... [17.08.05 16:33:14:131 EEST] a151819 WebGroup I SRVE0180I: [titan-web] [/titan-web] [Servlet.LOG]: /index.jsp: init [17.08.05 16:33:14:162 EEST] a151819 SystemOut O TitanListener: sessionCreated ... [17.08.05 16:33:48:286 EEST] 9085819 SystemOut O TitanListener: sessionDestroyed [17.08.05 16:33:48:286 EEST] 9085819 SystemOut O TitanListener: contextDestroyed |
Chapter 2. Design, build and test web components
Chapter 2. Design, build and test web components
Chapter 2. Design, build and test web components
Tutorials
- Appendix A. Additional materials
- WSAD 5.0 Practicing for IBM Test 000-287 Mind Map
- Deploy enterprise applications into servers
- Chapter 6. Assemble enterprise applications and deploy them in IBM WebSphere Application Server
- Configure resource and security-role references
- Design and develop custom tags
- Chapter 4. Demonstrate understanding of database connectivity and messaging within IBM WebShpere Application Server
- Chapter 5. EJB transactions
- Design and develop message-driven EJBs
- Design and develop entity EJBs
- Validate operational parameters of application server to support the enterprise application
- Chapter 1. Design, build and test reusable enterprise components
- Access container and server services from enterprise components
- Part I. Exam Objectives
- Explain implications of resource management on application design and implementation
- Manage end-user state and understand performance tradeoffs of using HTTP sessions
- Chapter 7. Validate, tune and troubleshoot an application within an IBM WebSphere Application Server environment
- Implement mechanisms for efficient inter-component calls
- IBM Test 000-287. Enterprise Application Development with IBM WebSphere Studio, V5.0 Study Guide
- Chapter 3. Develop clients that access the enterprise components
- Implement Java clients calling Web Services
- Configure JMS connection factories and destinations
- Design, develop and test JSPs
- Use JTA to control transaction demarcation
- Manipulate transactional behavior of EJBs using deployment descriptors
- Implement mechanisms which support loose coupling between clients and components
- Identify misbehaving application components
- Preface
- WSAD 5.0 Practicing for IBM Test 000-287
- Part II. Appendixes
- Interact with connection pools to obtain and release connections
- Describe the effects of a server failure on the application
- Test and debug enterprise components
- Chapter 2. Design, build and test web components
- Chapter 2. Design, build and test web components