Tải bản đầy đủ (.pdf) (10 trang)

WebSphere Studio Application Developer Version 5 Programming Guide part 26 docx

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (162 KB, 10 trang )

224 WebSphere Studio Application Developer Version 5 Programming Guide
Creating a server for testing
To test a Web application we require a server. Because our project is a J2EE 1.3
project we require a WebSphere Version 5 server (or a Tomcat server).
A server can be created automatically or manually:
 For automatic server creation, select the ItsoProGuideBasicWeb project and
Run on Server
(context). The dialog shown in Figure 7-39 is displayed.
Figure 7-39 Server selection dialog
The default selection is correct and clicking
OK
defines a server project
named Servers, a server named WebSphere v5.0 Test Environment, and
starts the server. The drawback of this method is that we cannot select a
name for the server and we cannot tailor the server before it starts.
Stop the server, delete it from the Server Configuration view and delete the
Servers project. We want to create a server manually.
 For manual creation of a server, open the Server perspective and select
New
-> Server and Server Configuration
. In the dialog (Figure 7-40) enter the
name of the server (for example, ItsoServer), set the folder as
ItsoProGuideServers (this creates the ItsoProGuideServers project), and
select
WebSphere version 5.0 -> Test Environment
.
Click
Next
and confirm that you want to create the ItsoProGuideServers
project.
Accept the default port of 9080 and click


Finish
.
Select the ItsoServer in the Server Configuration view and
Add ->
ItsoProGuide
(context). This adds the EAR project (with the Web module) to
the server.
The ItsoServer server also appears in the Servers view, from where it can be
started and stopped.
Chapter 7. Developing Web applications 225
Figure 7-40 Creating a WebSphere test server
Testing the application
Start the ItsoServer server.
While the server is starting, you can check its initialization message log on the
Console view. If the view is not visible, select
Window -> Show View -> Console

from the menu bar. You will know that the server is ready when you read the
message “Server server1 open for e-business“.
Select the ItsoProGuideBasicWeb project and
Run on Server
(context). When you
run a Web project itself, instead of a single HTML file, then the welcome page is
displayed. Welcome pages are defined in the deployment descriptor (web.xml) on
the Pages page. Usually the index.html file is the first in the list.
226 WebSphere Studio Application Developer Version 5 Programming Guide
If you are prompted to select a server, select the ItsoServer and also select
Set
server as project default (do not prompt)
. This stores a server as the default in

the properties of the Web project., where it can be changed at any time.
The Web browser window opens and displays the index page (Figure 7-2 on
page 182). In the customer ID field, type any number from 101 to 106 and submit
the form. The resulting page (Figure 7-3 on page 182) should display the
selected customer’s account list.
Working with filters
Servlet filtering is a new addition to the Servlet 2.3 API. It provides a new type of
reusable object called a filter, that can transform requests and responses on the
fly. You can chain filters together so that a group of filters can act on the input and
output of a specified resource or group of resources.
Filters typically include logging filters, image conversion filters, encryption filters,
and MIME type filters. Although filters are not servlets, their life cycle is very
similar.
Filters are handled in the following manner:
 The Web container determines which filters must be constructed for the Web
application, before a request causes a Web resource to be accessed.
 The container instantiates and initializes each filter (if this was not previously
done) by calling the filter’s init method.
 When the container receives a request for a Web resource, it creates a filter
chain containing the filters associated with the resource.
 The container invokes the chain’s doFilter method, which in turn invokes
each filter’s doFilter method. A filter’s doFilter method typically:
– Pre-processes the request object, or wraps it with a customized
implementation of ServletRequest or HttpServletRequest to modify
request headers or data.
– Pre-processes the response object, or wraps it with a customized
implementation of ServletResponse or HttpServletResponse to modify
response headers or data.
– Typically invokes the next filter on the chain by calling the chain’s doFilter
method, but may alternatively block the chain. After this step, the filter may

examine the response’s headers.
– Does additional post-processing to the request and response objects.
Chapter 7. Developing Web applications 227
 Finally, after all the filters on the chain have been invoked, the filter chain calls
the originally requested resource.
 Before a filter can be removed from service, the container must call its
destroy method.
Figure 7-41 shows how the chaining of filters work:
Figure 7-41 Filter chaining
Creating a filter in Application Developer
We implement a simple filter that audits all the banking transactions by writing an
audit trail to a file. This filter in invoked before the PerformTransaction servlet
gets control.
To create a new filter in Application Developer, open the
J2EE Navigator
view of
the ItsoProGuideBasicWeb project.
Create a new package (under Java Source) names itso.basicweb.filter.
Select the itso.basicweb.filter package and
New -> Filter
from the context
menu to start the
New Filter
wizard (Figure 7-42).
Resource
Web Container
Filter 1
doFilter
Filter 2
doFilter

Filter Chain
doFilter
Note: This is a simple example that uses a file for auditing. Such a design
should not be used in a real application.
228 WebSphere Studio Application Developer Version 5 Programming Guide
Figure 7-42 Creating a new filter (page 1)
Make sure the correct package (itso.basicweb.filter) is selected.
In the
Filter Name
field, type TransactionAuditingFilter. Our filter will audit
every transaction that is performed with the bank accounts, logging the
transaction type, time stamp, and parameters, as well as the client’s hostname
and IP address.
Click
Next
to proceed to the second page (Figure 7-43).
The wizard’s second page lets you select method stubs and deployment
descriptor information.
Chapter 7. Developing Web applications 229
Figure 7-43 Creating a new filter (page 2)
The filter has to be added to the Web deployment descriptor. Configure the
initialization parameter by clicking the respective
Add
. Enter pathname for the
parameter name and c:/transactionAudit.txt for its value.
Finally, we have to set with which servlets this filter should be associated. Click
the respective
Add
to open the
Choose a Servlet

dialog. Select
PerformTransaction and click
OK
.
Click
Finish
to complete the wizard. The TransactionAuditingFilter.java file is
opened for editing.
Note: To change the filter’s servlet associations or initialization parameters,
open the Web deployment descriptor on the
Filters
page.
230 WebSphere Studio Application Developer Version 5 Programming Guide
Editing the filter
Switch to the Java editor opened on the TransactionAuditingFilter.java file.
The source code of the sample filter is available in:
\sg246957\sampcode\dev-web\filter\TransactionAuditingFilter.java
Add an import statement and declare the following instance variable:
import java.io.RandomAccessFile;
private RandomAccessFile auditFile;
The auditFile property holds a reference to the audit file. Generate its getter
and setter methods by selecting the field in the Outline view and
Generate Getter
and Setter
from its context menu. Change the generated method access
modifiers from public to private (Figure 7-44):
Figure 7-44 Getter and setter methods for the auditFile property
The audit file should be opened upon the filter initialization. Edit the init method
as shown in Figure 7-45.
Figure 7-45 TransactionAuditingFilter init method

After opening the file for both read and write access, we move the file pointer to
the end, so that the file can be appended instead of overwritten.
Because we opened the file in the init method, we have to close it in the
destroy method (Figure 7-46).
private RandomAccessFile getAuditFile() {
return auditFile;
}
private void setAuditFile(RandomAccessFile auditFile) {
this.auditFile = auditFile;
}
public void init(FilterConfig config) throws ServletException {
String pathname = config.getInitParameter("pathname");
try {
setAuditFile(new RandomAccessFile(pathname, "rw"));
getAuditFile().seek(getAuditFile().length());
} catch (IOException e) {
e.printStackTrace());
}
}
Chapter 7. Developing Web applications 231
Figure 7-46 TransactionAuditingFilter destroy method
Finally, edit the filter’s doFilter method as shown in Figure 7-47.
Figure 7-47 TransactionAuditingFilter doFilter method
Save your changes and close the editor. The next time you perform a transaction
with any of the accounts, the audit file c:\transactionAudit.txt is created and
populated. See Figure 7-54 on page 236 for sample output of the filter (and the
listener that we create next).
public void destroy() {
try {
getAuditFile().close();

} catch (IOException e) {
e.printStackTrace();
}
}
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws ServletException, IOException {
String protocol = req.getProtocol();
String address = req.getRemoteAddr();
String host = req.getRemoteHost();
String transaction = req.getParameter("transaction");
String parameters = "";
java.util.Enumeration parameterNames = req.getParameterNames();
while (parameterNames.hasMoreElements()) {
String name = parameterNames.nextElement().toString();
String value = req.getParameter(name);
parameters += name + "=" + value + ", ";
}
parameters = parameters.substring(0, parameters.length() - 2);
String output = "- " + transaction +
" being performed from " + host + " (" + address +
") using " + protocol + " at " + new java.util.Date() +
" Parameters: " + parameters + "\r\n";
synchronized (getAuditFile()) {
getAuditFile().writeBytes(output);
}
System.out.println(output);
chain.doFilter(request, response);
}
232 WebSphere Studio Application Developer Version 5 Programming Guide
Working with listeners

Life-cycle listeners, now part of the Servlet API, enable you to be notified when
servlet contexts and HTTP sessions are created, destroyed or modified. They
give the application developer greater control over interactions with
ServletContext and HttpSession objects. Servlet context listeners manage
resources at an application level. Session listeners manage resources
associated with a particular client’s HTTP session.
Listeners are available for life-cycle events and for attribute modification events.
The listener developer creates a class that implements the interface
corresponding to the desired listener functionality:
 javax.servlet.ServletContextListener
Receives javax.servlet.ServletContextEvent events that notify that a
servlet context has just been created or is about to be destroyed.
 javax.servlet.ServletContextAttributeListener
Receives javax.servlet.ServletContextAttributeEvent events that notify
that an attribute in the servlet context has been added, removed, or modified.
 javax.servlet.http.HttpSessionListener
Receives javax.servlet.http.HttpSessionEvent events that notify that an
HTTP session object has just been created or is about to be destroyed.
 javax.servlet.http.HttpSessionAttributeListener
Receives javax.servlet.http.HttpSessionBindingEvent events that notify
that an attribute in an HTTP session has been added, removed, or modified.
Note that the same listener may implement any combination of the above
interfaces. At application startup time, the container uses introspection to create
an instance of the listener class and registers it with the appropriate event
generators.
As an example, we will create a listener that implements both the
HttpSessionListener and HttpSessionAttributeListener interfaces. It will be
called HttpSessionInspector and will print to the standard output detailed HTTP
session event notifications that can be used by the developer to determine:
 When HTTP sessions are created and destroyed.

 The size of the HTTP session objects at creation and destruction.
 When HTTP session attributes are added, removed or modified, and their
sizes.
Chapter 7. Developing Web applications 233
Creating a listener in Application Developer
To create a listener in Application Developer, open the
J2EE Navigator
view of
the ItsoProGuideBasicWeb project.
Create a new package (under Java Source) names itso.basicweb.listener.
Select the itso.basicweb.listener package under the Java Source folder and
then select
New -> Life-cycle Listener
from the context menu to start the
New
Life-cycle Listener
wizard (Figure 7-48):
Figure 7-48 Creating a new life-cycle listener (page 1)
Make sure the correct package (itso.basicweb.listener) is selected.
In the Listener Name field, type HttpSessionInspector. In the Listener Types
field, select both
Http Session Listener
and
Http Session Attribute Listener
. Click
Next
to continue to the second page (Figure 7-49):

×