Weblogic

1
Web applications are an important part of the Java 2 Enterprise Edition (J2EE) platform
because the Web components are responsible for key client-facing presentation and
business logic. A poorly designed Web application will ruin the best business-tier com-
ponents and services. In this chapter, we will review key Web application concepts and
technologies and their use in WebLogic Server, and we will provide a number of rec-
ommendations and best practices related to Web application design and construction
in WebLogic Server.
This chapter also provides the foundation for the discussion of recommended Web
application architectures in Chapter 2 and the construction and deployment of a com-
plex, realistic Web application in Chapters 3, 4, and 5.
Java Servlets and JSP Key Concepts
In this section we will review some key concepts related to Java Servlets and
JavaServer Pages. If you are unfamiliar with these technologies, or if you need addi-
tional background material, you should read one of the many fine books available on
the subject. Suggestions include Java Servlet Programming Bible by Suresh Rajagopalan
et. al. (John Wiley & Sons, 2002), Java Servlet Programming by Jason Hunter (O’Reilly &
Associates, 2001), and Core Servlets and JavaServer Pages by Marty Hall (Prentice Hall
PTR, 2000).
Building Web Applications
in WebLogic
C HAPTE R
1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 1

Characteristics of Servlets
Java servlets are fundamental J2EE platform components that provide a
request/response interface for both Web requests and other requests such as XML
messages or file transfer functions. In this section, we will review the characteristics of
Java servlets as background for a comparison of servlets with JavaServer Pages (JSP)
technology and the presentation of best practices later in the chapter.
Servlets Use the Request/Response Model
Java servlets are a request/response mechanism: a programming construct designed to
respond to a particular request with a dynamic response generated by the servlet’s spe-
cific Java implementation. Servlets may be used for many types of request/response
scenarios, but they are most often employed in the creation of HyperText Transfer Pro-
tocol (HTTP) responses in a Web application. In this role, servlets replace other HTTP
request/response mechanisms such as Common Gateway Interface (CGI) scripts.
The simple request/response model becomes a little more complex once you add
chaining and filtering capabilities to the servlet specification. Servlets may now partic-
ipate in the overall request/response scenario in additional ways, either by prepro-
cessing the request and passing it on to another servlet to create the response or by
postprocessing the response before returning it to the client. Later in this chapter, we’ll
discuss servlet filtering as a mechanism for adding auditing, logging, and debugging
logic to your Web application.
Servlets Are Pure Java Classes
Simply stated, a Java servlet is a pure Java class that implements the javax.servlet
.Servlet interface. The application server creates an instance of the servlet class and
uses it to handle incoming requests. The Servlet interface defines the set of methods
that should be implemented to allow the application server to manage the servlet life
cycle (discussed later in this chapter) and pass requests to the servlet instance for pro-
cessing. Servlets intended for use as HTTP request/response mechanisms normally
extend the javax.servlet.http.HttpServlet class, although they may imple-
ment and use the Servlet interface methods if desired. The HttpServlet class
implements the Servlet interface and implements the init(), destroy(), and
service() methods in a default manner. For example, the service() method in
HttpServlet interrogates the incoming HttpServletRequest object and for-
wards the request to a series of individual methods defined in the HttpServlet class
based on the type of request. These methods include the following:
■■ doGet() for handling GET, conditional GET, and HEAD requests
■■ doPost() for POST requests
■■ doPut() for PUT requests
■■ doDelete() for DELETE requests
■■ doOptions() for OPTIONS requests
■■ doTrace() for TRACE requests
2 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 2

The doGet(), doPost(), doPut(), and doDelete() methods in HttpServlet
return a BAD_REQUEST (400) error as their default response. Servlets that extend
HttpServlet typically override and implement one or more of these methods to gen-
erate the desired response. The doOptions() and doTrace() methods are typically
not overridden in the servlet. Their implementations in the HttpServlet class are
designed to generate the proper response, and they are usually sufficient.
A minimal HTTP servlet capable of responding to a GET request requires nothing
more than extending the HttpServlet class and implementing the doGet()
method.
WebLogic Server provides a number of useful sample servlets showing the basic
approach for creating HTTP servlets. These sample servlets are located in the
samples/server/examples/src/examples/servlets subdirectory beneath
the Web-Logic Server home directory, a directory we refer to as $WL_HOME throughout
the rest of the book. We will examine some additional example servlets in detail
during the course of this chapter. These example servlets are available on the compan-
ion Web site for this book at http://www.wiley.com/compbooks/masteringweblogic.
Creating the HTML output within the servlet’s service() or doXXX() method is
very tedious. This deficiency was addressed in the J2EE specification by introducing a
scripting technology, JavaServer Pages (JSP), discussed later in this chapter.
Servlets Have a Life Cycle
A servlet is an instance of the servlet class and has a life cycle similar to that of any
other Java object. When the servlet is first required to process a request, the application
server loads the servlet class, creates an instance of the class, initializes the instance,
calls the servlet’s init() method, and calls the service() method to process the
request. In normal servlet operation, this same instance of the servlet class will be used
for all subsequent requests.
Servlets may be preloaded during WebLogic Server startup by including the <load-
on-startup> element in the web.xml file for the Web application. You can also pro-
vide initialization parameters in this file using <init-param> elements. WebLogic
Server will preload and call init() on the servlet during startup, passing the specified
initialization parameters to the init() method in the ServletConfig object.
An existing servlet instance is destroyed when the application server shuts down or
intends to reload the servlet class and create a new instance. The server calls the
destroy() method on the servlet prior to removing the servlet instance and unload-
ing the class. This allows the servlet to clean up any resources it may have opened dur-
ing initialization or operation.
Servlets Allow Multiple Parallel Requests
Servlets are normally configured to allow multiple requests to be processed simultane-
ously by a single servlet instance. In other words, the servlet’s methods must be
thread-safe. You must take care to avoid using class- or instance-level variables unless
access is made thread-safe through synchronization logic. Typically, all variables and
objects required to process the request are created within the service() or doXXX()
method itself, making them local to the specific thread and request being processed.
Building Web Applications in WebLogic 3
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 3

BEST PRACTICE Servlets that allow multiple parallel requests must be
thread-safe. Do not share class- or instance-level variables unless
synchronization logic provides thread safety.
Servlets may be configured to disallow multiple parallel requests by defining the
servlet class as implementing the SingleThreadModel interface:
...
public class TrivialSingleThreadServlet
extends HttpServlet implements SingleThreadModel
{
public void init(ServletConfig config) throws ServletException
{
super.init(config);
System.out.println(“Here!”);
}
...
This simple change informs the application server that it may not process multiple
requests through the same servlet instance simultaneously. The application server can
honor this restriction in multiple ways: It may block and queue up requests for pro-
cessing through a single instance, or it may create multiple servlet instances as needed
to fulfill parallel requests. The servlet specification does not dictate how application
servers should avoid parallel processing in the same instance.
WebLogic Server satisfies the single-threaded requirement by creating a small pool
of servlet instances (the default pool size is five) that are used to process multiple
requests. In older versions of WebLogic Server, multiple parallel requests in excess of
the pool size would block waiting for the first available servlet instance. This behavior
changed in WebLogic Server 7.0. The server now creates, initializes, and discards a new
instance of the servlet for each request rather than blocking an execute thread under
these conditions. Set the pool size properly to avoid this extra servlet creation and ini-
tialization overhead.
You can configure the size of the pool at the Web application level using the
single-threaded-servlet-pool-size element in the weblogic.xml deploy-
ment descriptor. If you choose to employ single-threaded servlets in high-volume
applications, consider increasing the pool size to a level comparable to the number of
execute threads in the server to eliminate the potential overhead required to create
extra servlet instances on the fly to process requests.
Although instance variables are safe to use in single-threaded servlets, class-level
static variables are shared between these instances, so access to this type of static data
must be thread-safe even when using the SingleThreadModel technique. Deploy-
ing and executing this TrivialSingleThreadServlet example verifies this pool-
ing behavior in WebLogic Server. The first servlet request causes WebLogic Server to
create five instances of the servlet, as evidenced by five separate invocations of the
init() method and the subsequent writing of five “Here!” messages in the log.
4 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 4

BEST PRACTICE In general, you should avoid using single-threaded
servlets. If you find that you need to use servlets that implement the
SingleThreadModel, use the single-threaded-servlet-pool-size element
to set the pool size properly to avoid the overhead of creating and initializing
extra servlet instances to handle peaks in the number of concurrent requests to
the servlet.
Servlets May Access Request Data
The HttpServletRequest parameter passed in to the service() or doXXX()
method contains a wealth of information available to the servlet during the processing
of the request. Useful data in the HttpServletRequest is summarized in Table 1.1.
This is not an exhaustive list of the methods available on the HttpServletRe-
quest class or its superclass, ServletRequest. Refer to the servlet javadocs at
http://java.sun.com/products/servlet/2.3/javadoc/index.html or a good reference
book on servlets for a complete list including parameter types, return types, and other
details.
Table 1.1 Information Available in the HttpServletRequest
TYPE OF INFORMATION ACCESS METHODS
Parameters passed in the query getParameterNames(),
string or through form input fields getParameter(),
getParameterValues(),
getQueryString()
Server information getServerName(), getServerPort()
Client characteristics getRemoteAddr(), getRemoteHost(),
getAuthType(), getRemoteUser()
Request information getContentType(),
getContentLength(),
getProtocol(), getScheme(),
getRequestURI()
HTTP headers getHeaderNames(), getHeader(),
getIntHeader(), getDateHeader()
Cookies sent by browser getCookies()
Session information getSession(),
getRequestedSessionId(),
isRequestedSessionIdValid(), ...
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 5

A useful servlet packaged with the WebLogic Server examples, SnoopServlet,
illustrates the use of many of the methods available on the HttpServletRequest
object. For example, this section of SnoopServlet illustrates how to retrieve and dis-
play the names and values of all parameters passed to the servlet:
...
Enumeration e = req.getParameterNames();
if (e.hasMoreElements()) {
out.println(“<h1>Servlet parameters (Single Value style):</h1>”);
out.println(“<pre>”);
while (e.hasMoreElements()) {
String name = (String)e.nextElement();
out.println(“ “ + name + “ = “ + req.getParameter(name));
}
out.println(“</pre>”);
}
...
This servlet can be very useful for debugging HTML forms during development.
Specify SnoopServlet as the action for an HTML form to view all of the parameters,
cookies, and headers sent by the browser during submission of the form. Nothing is
more frustrating than spending time debugging a servlet only to find that the HTML
form had an improperly named input item.
BEST PRACTICE Use the SnoopServlet as an action target during
development and debugging to inspect request information and verify HTML
forms.
Note that SnoopFilter, a servlet filter discussed later in this chapter, provides a
superior mechanism for viewing request information for some or all pages in the Web
application.
Servlets Use Session Tracking
A servlet is a request/response mechanism that treats each incoming request as an
independent processing event with no relationship to past or future requests. In other
words, the processing is stateless. The HTTP protocol is also a stateless protocol: Each
request from the Web browser is independent of previous or subsequent requests.
Linking current requests to previous requests from the same client requires a mecha-
nism for preserving context or state information from request to request. There are a
number of HTML-based techniques for preserving context or state information:
■■ Cookies may be set in previous requests and passed back to the server on subse-
quent requests.
■■ URL-rewriting may be used to encode small amounts of context information on
every hyperlink on the generated page.
■■ Hidden form fields containing context information may be included in forms.
6 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 6

These techniques all have limitations, and none provides the robust data types and
flexibility needed to implement true state management. Fortunately, the session track-
ing capability defined in the J2EE servlet model provides an excellent solution.
Session tracking provides a flexible hash-table-like structure called an HttpSes-
sion that can be used to store any serializable Java object and make it available in sub-
sequent requests. To identify the specific client making the request and look up its
session information, session tracking uses a cookie or URL-encoded session ID passed
to the server on subsequent requests. In WebLogic Server, this session ID has the name
JSESSIONID by default and consists of a long hash identifying the client plus
creation-time and cluster information. The format of the session ID is
JSESSIONID=SESSION_ID!PRIMARY_JVMID_HASH!SECONDARY_JVM_HASH!CREATION_TIME
WebLogic Server uses exclamation marks to separate portions of the session ID. The
first portion is used by the session tracking implementation in WebLogic Server to look
up the client’s HttpSession object in the Web application context. Subsequent por-
tions of the session ID are used to identify primary and secondary servers for this client
in a WebLogic Server cluster and to track the creation time for this session. Chapter 11
will discuss WebLogic Server clustering in detail as part of the discussion of adminis-
tration best practices.
Using session tracking in a servlet is as simple as calling the getSession()
method to retrieve or create the HttpSession object for this client and then utilizing
the HttpSession interface to get and set attributes in the session. For a good exam-
ple, see the SessionServlet example provided in the WebLogic Server examples.
WebLogic Server supports several forms of session persistence, a mechanism for
providing session failover. The two most commonly used forms are in-memory repli-
cation and JDBC persistence. When using these types of session persistence, be careful
not to place very large objects in the HttpSession. WebLogic Server tracks changes
to the session object through calls to the setAttribute() method. At the end of each
request, the server will serialize each new or modified attribute, as determined by the
arguments to any setAttribute() calls, and persist them accordingly.
Recognize that persisting a session attribute will result in WebLogic Server serializ-
ing the entire object graph, starting at the root object placed in the HttpSession. This
can be a significant amount of data if the application stores large, coarse-grained
objects in the session. Multiple fine-grained objects can provide superior performance,
provided that your application code updates only a subset of the fine-grained objects
(using setAttribute) in most cases. We will talk more about in-memory session
replication and clustering in Chapter 11.
BEST PRACTICE Use session tracking to maintain state and contextual
information between servlet requests. When using session persistence, avoid
placing large objects in the session if your application tends to update only a
small portion of these objects for any particular request. Instead, use multiple
fine-grained objects to reduce the cost of session persistence.
To summarize, servlets are a reliable pure-Java mechanism for processing HTTP
requests. It can be tedious to generate the HTML response through the simple
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 7

println() methods available on the response Writer object, however. As we will
discuss in Chapter 2, servlets are better suited for processing incoming requests and
interacting with business objects and services than for the generation of HTTP
responses.
If servlets are a tedious way to create HTML, what is available in the J2EE specifica-
tion for efficiently creating HTML responses? JavaServer Pages technology, the subject
of the next section of this chapter, is specifically design to be a powerful tool for creat-
ing HTML.
Characteristics of JavaServer Pages
JavaServer Pages (JSP) technology was introduced in the J2EE platform to provide an
alternative to servlets for the generation of server-side HTML content. Although a
detailed discussion of JSP technology is beyond the scope of this book, some key con-
cepts and characteristics are worth a brief review.
JSP Is a Scripting Technology
Recall that one of the important characteristics of servlets is their pure Java nature.
Servlets are Java classes that are written, compiled, and debugged much like any Java
class. JavaServer Pages, on the other hand, are a script-based technology similar to
Microsoft’s Active Server Pages (ASP) technology or Allaire’s Cold Fusion scripting
language. Like these scripting languages, special tags and script elements are added to
a file containing HTML to produce a combination of static and dynamic content. In the
case of JSP, these added elements are Java code or special JSP tags that interact with
Java beans and other J2EE components in the application.
JSP Pages Are Converted to Servlets
The key to understanding JSP pages is to recognize that the JSP file itself is simply
the input for a multistep process yielding a servlet. In the key processing step, the
JSP page is parsed by the application server and converted to the equivalent pure-
Java servlet code. All text that is not part of JSP tags and scripting elements is assumed
to be part of the HTTP response. This text is placed in out.print() calls within the
generated servlet request-processing method. All Java scripting elements and tags
become additional Java code in the servlet. The generated servlet is then compiled,
loaded, and used to process the HTTP request in a manner identical to a normal servlet.
Figure 1.1 depicts this process for a trivial sample JSP page with a small amount of
scripted Java code embedded on the page. The sample.jsp page is converted to the
equivalent pure-Java servlet code, compiled into a servlet class, and used to respond to
the original and subsequent HTTP requests.
The parsing, conversion, compiling, and classloading steps required to accomplish
this transformation are handled by the application server. You don’t have to perform
any of these steps ahead of time or register the resulting servlet—all of this is done
automatically by the server. Note that the processing and compiling can be done prior
to deployment using utilities provided by WebLogic Server, a technique known as pre-
compiling the JSP pages. We will discuss this technique in detail later in this chapter.
8 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 8

Figure 1.1 JSP page is converted to a servlet.
In WebLogic Server, the resulting servlet is a subclass of weblogic.servlet
.jsp.JspBase by default. JspBase is a WebLogic-provided class that extends
HttpServlet and forwards service() calls to a method called _jspService().
You may also create a custom base class for JSP-generated servlets to replace the
default JspBase class, a technique discussed at end of this chapter.
Many Tags and Scripting Elements Are Available
JSP technology provides a rich set of scripting elements and tags for creating dynamic
content. Table 1.2 lists some of the important elements available.
Table 1.2 JSP Syntax Elements
ELEMENT SYNTAX DESCRIPTION
Scriptlet <% scriptlet code %> Java code placed directly in
_jspservice() method at this
location.
Declaration <%! declaration %> Java code placed within the
generated servlet class above the
_jspservice() method
definition. This usually defines
class-level methods and variables.
Expression <%= expression %> Java expression evaluated at run
time and placed in the HTML
output.
(continued)
sample.jsp
<html>
<head>
<title>A Sample Servlet</title>
</head>
<body>
<H1>A Sample JSP Page</H1>
<H2>Counting Fun</H2>
<% for (int jj=1; jj<=10; jj++) { %>
<%= jj %><br>
<% } %>
</body>
</html>
<html>
. . .
<H2>Counting Fun</H2>
1<br>
2<br>
. . .
</html>
_sample.java
_sample.class
Servlet Source Code
Servlet Class
HTTP Response
HTTP Request
from Browser
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 9

Table 1.2 (continued)
ELEMENT SYNTAX DESCRIPTION
page <%@ page attribute= Controls many page-level
directive ”value” ... %> attributes and behaviors.
Important attributes include
import, buffer, errorPage,
and extends.
Include <%@ include Inserts the contents of the
file=”filename” %> specific file in the JSP page and
parses/compiles it.
Taglib <%@ taglib uri= Defines a tag library and sets the
”...” prefix=”...” %> prefix for subsequent tags.
jsp:include <jsp:include Includes the response from a
page=”...”/> separate page in the output of
this page.
jsp:forward <jsp:forward Abandons the current response
page=”...”/> and passes the request to a new
page for processing.
jsp:useBean <jsp:useBean Declares the existence of a bean
id=”...” scope=”...” with the given class, scope, and
class=”...”/> instance name.
Many more elements and tags are available. A detailed discussion of these elements
is beyond the scope of this book. Consult one of the books listed at the beginning of this
chapter for a complete list of JSP elements and tags, or browse Sun’s JSP area at
http://java.sun.com/products/jsp/ for more information.
All Servlet Capabilities Are Available
Because JSP pages are converted to servlets, all of the capabilities and techniques avail-
able in servlets are also available in JSP pages. The HttpServletRequest and
HttpServletResponse parameters are available, along with a number of prede-
fined variables available in the JSP page, as listed in Table 1.3.
Table 1.3 JSP Implicit Objects
OBJECT TYPE DESCRIPTION
request javax.servlet.http Provides access to request
.HttpServletRequest information and attributes set
at the request scope.
response javax.servlet.http Reference to the response
.HttpServletResponse object being prepared for
return to the client.
10 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 10

Table 1.3 (continued)
OBJECT TYPE DESCRIPTION
pageContext javax.servlet.jsp Provides access to attributes
.PageContext set at the page scope.
session javax.servlet.http Session object for this client;
.HttpSession provides access to attributes
set at the session scope.
application javax.servlet Application context; provides
.ServletContext access to attributes set at the
application scope.
out javax.servlet.jsp PrintWriter object used to
.JspWriter place text output in the HTTP
response.
config javax.servlet Reference to the servlet
.ServletConfig configuration object set
during initialization; provides
access to initialization
parameters.
JSP scriptlet code may make use of all implicit objects because scriptlet code is
placed in the generated _jspService() method after these objects are defined, as
shown in this partial listing:
...
public void _jspService(javax.servlet.http.HttpServletRequest request,
javax.servlet.http.HttpServletResponse response)
throws java.io.IOException, javax.servlet.ServletException
{
// declare and set well-known variables:
javax.servlet.ServletConfig config = getServletConfig();
javax.servlet.ServletContext application =
config.getServletContext();
Object page = this;
javax.servlet.jsp.JspWriter out;
javax.servlet.jsp.PageContext pageContext =
javax.servlet.jsp.JspFactory.getDefaultFactory().getPageContext(
this, request, response, null, true, 8192, true);
out = pageContext.getOut();
javax.servlet.http.HttpSession session = request.getSession(true);
...
// scriptlet code and generated out.print() statements go here
...
}
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 11

You should recognize that these implicit objects are available in scriptlet code but
are not automatically available in methods defined using the <%! ... %> declaration
scripting element or in methods in a custom base class used for the JSP page. It is com-
mon to pass the necessary implicit objects to these methods as parameters.
Session tracking is available by default in JSP pages, providing the session
implicit object throughout the scriptlet code. If your application is not using session
tracking, you should disable it to avoid unnecessary session persistence. Although
there is no explicit way to disable session tracking for the entire Web application,
servlets will not create sessions unless the servlet code calls the getSession()
method. JSP pages may disable sessions using the page directive:
<%@ page session=”false” %>
Even if your JSP does nothing with the session information, WebLogic Server must
persist the last access time for the session at the end of the request processing. It is best
to explicitly disable session tracking in JSP pages that do not use it.
BEST PRACTICE Disable session tracking in JSP pages that do not require
this feature to avoid unnecessary session persistence.
Like servlets, JSP pages are normally multithreaded and may process multiple
requests simultaneously. The same thread-safety restrictions that apply to servlets also
apply to JSP pages unless the JSP is configured to be single threaded. In a JSP page a
special page directive is used to configure this attribute:
<%@ page isThreadSafe=”false” %>
If the isThreadSafe attribute is set to false, the resulting servlet will implement
the SingleThreadModel interface, and WebLogic Server will create a pool of servlet
instances and synchronize access to them in the same manner it uses for a pure-Java
servlet that implements this interface.
BEST PRACTICE As with servlets, you should generally avoid declaring JSP
pages to be single threaded. If you find yourself needing to do that, make sure
that the pool size is large enough to avoid creating and initializing new
instances on the fly to process concurrent requests.
JSP Response Is Buffered
As we said, servlets and JSP pages are request/response mechanisms: An HTTP
request is made by the browser, and an HTML response is generated by the servlet
or JSP page. In both cases, this response is normally buffered, or held in memory
on the server temporarily, and sent back to the calling browser at the end of the
processing.
12 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 12

By default, output created using the print() and println() methods on the
implicit JspWriter object (out) are buffered, along with HTTP headers, cookies, and
status codes set by the page. Buffering provides you with these important benefits:
■■ Buffered content may be discarded completely and replaced with new content.
The jsp:forward element relies on this capability to discard the current
response and forward the HTTP request to a new page for processing. Note
that the errorPage directive uses jsp:forward to send the processing to the
error page if an error is caught in the JSP page, so buffering is also required for
proper error-page handling.
■■ Buffering allows the page to add or change HTTP headers, cookies, and status
codes after the page has begun placing HTML content in the response. Without
buffering, it would be impossible to add a cookie in the body of the JSP page or
change the response to be a redirect (302) to a different page once print() or
println() has been called because the headers and cookies have already
been sent.
When the buffer fills, the response is committed, and the first chunk of information
is sent to the browser. Once this commit occurs, the server will no longer honor
jsp:forward, HTTP header changes (such as redirects), or additional cookies. The
server will generate an IllegalStateException if any of these operations is
attempted after the buffer fills and the response is committed.
The default size of the JSP output buffer is 8KB in WebLogic Server, which you can
control using the page directive in each JSP page:
<%@ page buffer=”32kb” %>
Output buffering may also be turned off using this directive by specifying “none”
for a size, but this practice is not recommended.
Output buffers should be set to at least 32KB in most applications to avoid filling the
buffer and committing the response before the page is complete. The minor additional
memory requirement (32KB times the number of threads) is a small price to pay for
correct error-page handling and the ability to add cookies and response headers at any
point in large pages.
BEST PRACTICE Always use output buffering in JSP pages. Increase the
size of the buffer to at least 32KB to avoid redirect, cookie, jsp:forward, and
error-page problems.
JSP Pages Have Unique Capabilities
Unique capabilities are available in JSP pages that are not present in servlets. Two
important JSP-only capabilities are custom tags and jsp:useBean elements.
Custom tags provide a mechanism to interact with a custom-developed Java class
that encapsulates business logic, presentation logic, or both. Custom tag elements are
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 13

placed in the JSP page by the developer and then parsed and preprocessed by the
application server during the conversion from JSP to servlet. The tag elements are con-
verted by the server to the Java code required to interact with the tag class and perform
the desired function. Later in this chapter we will discuss custom tags in more detail
and present best practices for their use in WebLogic Server.
The jsp:useBean element provides a mechanism to declare and establish the
existence of a bean instance for use in scriptlet code or in conjunction with jsp:
getProperty and jsp:setProperty tags. The jsp:useBean syntax allows the
developer to specify the class of the bean, the name of the reference to the bean, the
type of the reference, and the scope in which the bean should be created. We will dis-
cuss the strengths and weaknesses of the jsp:useBean element later in this chapter
during the discussion of best practices.
To summarize, JavaServer Pages technology is a scripting language used to create
HTML responses. JSP pages are converted to pure-Java servlets by the application
server during processing, and they can perform nearly any task a pure-Java servlet can
perform. JSP pages also have unique directives, features, and customization capabili-
ties unavailable to servlets.
Why not use JSP for everything and forget servlets completely? Although it is possible
to do so, servlets often provide a better mechanism for implementing presentation-tier
business logic. Chapter 2 will address this issue in detail and provide guidance for the
proper use of each technology.
Web Application Best Practices
Now that you have reviewed some of the key concepts related to Web applications in
WebLogic Server, it’s time to dig in and discuss best practices. So many options are
available to designers and developers of J2EE Web applications that it would require
an entire book to list and explain all of the Web application best practices we could con-
ceivably discuss. In this section, we’ve attempted to discuss the best practices we feel
are applicable to the widest variety of development efforts or are most likely to
improve the quality or performance of your WebLogic Server Web applications.
The best practices contained in this chapter cover everything from recommended
techniques for using custom tags to proper packaging of your Web application to
caching page content for performance. They are presented in no particular order of
importance, as the importance of a given best practice depends greatly on the particu-
lar application you are building.
Ensure Proper Error Handling
Unhandled exceptions that occur during the execution of a servlet or JSP-generated
servlet cause the processing of that page to stop. Assuming the response has not been
committed, the JSP output buffer will be cleared and a new response generated and
returned to the client. By default, this error response contains very little useful infor-
mation apart from the numeric error code.
14 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 14

What you need is a friendly, informative error page containing as much information
as possible to help during debugging. Fortunately, there is a built-in mechanism for
specifying a custom error page for use in handling server errors during processing.
First, you construct an error page JSP to present the error information to the user in
a friendly fashion. At a minimum, it should display the exception information and a
stack trace. To be more useful during debugging, it can display all request and HTTP
header information present using the same methods employed by SnoopServlet,
discussed earlier. Portions of an example error page are shown in Listing 1.1. The entire
page is available on the companion Web site (http://www.wiley.com/compbooks
/masteringweblogic).
<%@ page isErrorPage=”true” %>
<html>
<head><title>Error During Processing</title></head>
<body>
<h2>An error has occurred during the processing of your request.</h2>
<hr>
<h3><%= exception %></h3>
<pre>
<%
ByteArrayOutputStream ostr = new ByteArrayOutputStream();
exception.printStackTrace(new PrintStream(ostr));
out.print(ostr);
%>
</pre>
<hr>
<h3>Requested URL</h3>
<pre>
<%= HttpUtils.getRequestURL(request) %>
</pre>
<h3>Request Parameters</h3>
<pre>
<%
Enumeration enum = request.getParameterNames();
while(enum.hasMoreElements()){
String key = (String)enum.nextElement();
String[] paramValues = request.getParameterValues(key);
for(int i = 0; i < paramValues.length; i++) {
out.println(key + “ : “ + paramValues[i]);
}
}
%>
</pre>
<h3>Request Attributes</h3>
<pre>
Listing 1.1 ErrorPage.jsp. (continued)
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 15

...
</pre>
<h3>Request Information</h3>
<pre>
...
</pre>
<h3>Request Headers</h3>
<pre>
...
</pre>
Listing 1.1 (continued)
Second, place a <%@ page errorPage=”...” %> directive on all JSP pages in the
application specifying the location of this error JSP page. Listing 1.2 presents a simple
example JSP page that declares the error page explicitly. Normally you would do this
through a common include file shared by all pages rather than including the directive
on every page.
<%@ page errorPage=”ErrorPage.jsp” %>
<html>
<head></head>
<body>

<% String s = null; %>
The string length is: <%= s.length() %><p>
</body>
</html>
Listing 1.2 ErrorCreator.jsp.
Accessing the ErrorCreator.jsp page from a browser now causes a useful error
message to be displayed to the user. The page could conform to the look and feel of the
site itself and could easily include links to retry the failed operation, send an email to
someone, or go back to the previous page.
As an alternative to specifying the errorPage on each individual JSP page, a
default error-handling page may be specified for the entire Web application using the
error-page element in web.xml:
<error-page>
<error-code>500</error-code>
<location>/ErrorPage.jsp</location>
</error-page>
16 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 16

These two mechanisms for specifying the error page may look very similar but are,
in fact, implemented quite differently by WebLogic Server. The <%@ page error-
Page=”...” %> directive modifies the generated servlet code by placing all JSP
scriptlet code, output statements, and other servlet code in a large try/catch block.
Specifying the error page in web.xml does not affect the generated servlet code in any
way. Instead, uncaught exceptions that escape the _jspService() method in the
original page are caught by the Web container and forwarded to the specified error
page automatically.
Which technique is best? Unless the target error page must differ based on the page
encountering the error, we recommend the error-page element in web.xml for the
following reasons:
■■ A declarative and global technique has implicit benefits over per-page tech-
niques. Individual pages that require different error pages can easily override
the value in web.xml by including the page directive.
■■ The information describing the original page request is more complete if the
error-page element is used rather than the page directive. Specifically, call-
ing request.getRequestURL() in the error page returns the URL of the
original page rather than the URL of the error page, and additional attributes
are placed on the request that are not present if the page directive is employed.
Note that WebLogic Server correctly includes the special javax.servlet.
error.request_uri attribute in the request after forwarding to the error
page using either the error-page element or the page directive, so there is
always at least one consistent way to retrieve the original page name.
The examples available for this chapter include error-creation pages using both
techniques for your examination. ErrorCreator.jsp uses the page directive, and
BadErrorCreator.jsp simply creates an error without specifying an error page,
thereby relying on the error-page element in web.xml to specify the correct error
page. Accessing these two pages from your browser and observing the output will
help you understand the differences in request information available depending on the
technique used to declare the error page.
BEST PRACTICE Create a friendly and useful error page, and make it the
default error page for all server errors using the error-page element in
web.xml. Override this default error page using the page directive in specific
pages, if necessary.
Use jsp:useBean to Reduce Scriptlet Code
The jsp:useBean element provides a powerful mechanism for declaring beans on a
JSP page. Beans are given names by this element and may be declared in different
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 17

scopes: page, request, session, and application. The scope determines the bean’s avail-
ability in other servlets and page requests:
■■ Page scope places the bean reference in the PageContext and makes it avail-
able in subsequent scriptlet code, elements, and custom tags during this page
processing only. This is the default scope if no scope attribute is present in the
jsp:useBean element.
■■ Request scope places the bean reference in the HttpServletRequest using
setAttribute(), making it available on this page and in any pages included
during this processing cycle using jsp:include or jsp:forward elements.
■■ Session scope places the bean reference in the HttpSession object for this
client, making it available on this page and in all subsequent requests by this
particular client until removed from the session.
■■ Application scope places the bean in the WebApplicationContext, which
makes it available to any page in this particular Web application until the
application server is shut down or the Web application is redeployed.
In its simplest form, the jsp:useBean element can be considered a shorthand for
scriptlet code that establishes a bean instance in the given scope. For example, consider
the element shown here:
<jsp:useBean id=”currentrez” class=”examples.Reservation” />
This can be considered equivalent to the following scriptlet code:
<% examples.Reservation currentrez = new examples.Reservation(); %>
The true advantage of jsp:useBean is not apparent until you use a scope other
than page. For example, the following element declaring the Reservation object to
be in the session scope requires significant coding in the equivalent scriptlet. The
jsp:useBean element is straightforward:
<jsp:useBean id=”currentrez”
class=”examples.Reservation” scope=”session” />
The corresponding scriptlet code is fairly complex:
<%
Object obj = session.getAttribute(“currentrez”);
if (obj == null) {
obj = new examples.Reservation();
session.setAttribute(“currentrez”, obj);
}
examples.Reservation currentrez = (examples.Reservation)obj;
%>
18 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 18

Clearly, there is an advantage to using the jsp:useBean element in this case. Note
that the name of the bean, defined by the id attribute in jsp:useBean, will be used
as the key in the getAttribute() call to find the bean in the HttpSession object.
It is important that the name be unique enough to avoid naming conflicts with other
items placed in the session.
BEST PRACTICE Declare beans used in JSP pages using jsp:useBean,
especially when the bean is in the request, session, or application scope. Use
names descriptive enough to avoid naming conflicts with other beans defined
at the same scope.
Beans declared using jsp:useBean are available in subsequent scriptlet code and in
special jsp:getProperty and jsp:setProperty elements used to access and mod-
ify bean attributes. These special elements can be used to eliminate some scriptlet code
from your JSP pages. For example, the jsp:getProperty element eliminates the need
for expression scriptlets when displaying data in beans, as shown in Listing 1.3.
<%@ page import=”mastering.weblogic.ch01.example1.Person” %>
<jsp:useBean id=”pp” class=”mastering.weblogic.ch01.example1.Person”
scope=”request” />
<html>
<head><title>Show the Person Data</title></head>
<body>
Here is the Person from the request:<BR>
First Name: <jsp:getProperty name=”pp” property=”firstName”/><BR>
Last Name: <jsp:getProperty name=”pp” property=”lastName”/><BR>
Age: <jsp:getProperty name=”pp” property=”age”/><BR>
</body>
</html>
Listing 1.3 ShowPerson.jsp.
This represents a slight improvement in readability over the equivalent code using
expression scriptlets, and it may prove easier to maintain for nonprogrammers work-
ing with the visual elements on JSP pages.
The jsp:setProperty element calls set methods on the related bean, passing in
data supplied in the element or from the current HttpServletRequest object,
depending on the attributes supplied in the element. For example, in the JSP action
page shown in Listing 1.4, the jsp:setProperty elements interrogate the HTTP
request and place data for lastName, firstName, and age in the corresponding bean
attributes:
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 19

<%-- Create a “Person” object, load it with data from request params,
and store it on http request --%>
<%@ page import=”mastering.weblogic.ch01.example1.Person” %>
<jsp:useBean id=”pp” class=”mastering.weblogic.ch01.example1.Person”
scope=”request” />
<jsp:setProperty name=”pp” property=”lastName” />
<jsp:setProperty name=”pp” property=”firstName” />
<jsp:setProperty name=”pp” property=”age” />
<jsp:forward page=”ShowPerson.jsp” />
Listing 1.4 EnterPerson_action.jsp.
The jsp:useBean element also includes an initialization feature allowing the exe-
cution of scriptlet code or custom tags if the declared bean was not found in the speci-
fied scope. The initialization code may also use jsp:setProperty elements to
initialize the bean and may perform any operations normally allowed in JSP scriptlet
code. This feature is useful when declaring a bean in the request or session scope that
may already have been defined by an earlier page in the process. For example, the fol-
lowing element declares a bean at the session scope and initializes its attributes using
the jsp:setProperty elements if it was not already present in the session:
<jsp:useBean id=”pp” class=” mastering.weblogic.ch01.example1.Person”
scope=”session”>
<jsp:setProperty name=”pp” property=”lastName” value=”Nyberg” />
<jsp:setProperty name=”pp” property=”firstName” value=”Greg” />
<jsp:setProperty name=”pp” property=”age” value=”39”/>
</jsp:useBean>
We will make limited use of the jsp:useBean element and related jsp:getProp-
erty and jsp:setProperty elements during the construction of the sample Web
application in Chapters 3 and 4.
Use Custom Tags for Selected Behaviors
Custom tags are a powerful mechanism for extending the basic JSP tag syntax to
include custom-developed tags for interacting with Java components, modifying
response content, and encapsulating page logic. As with jsp:useBean elements,
using custom tags can reduce or eliminate the need for scriptlet code in the JSP page
and improve maintainability. Custom tags are more powerful and flexible than
jsp:useBean elements because they allow the manipulation of JSP content and pro-
vide a much richer interface.
The power of custom tags comes with a cost, of course: complexity. Unlike
jsp:useBean elements, which are essentially a shortcut for common tasks typically
done through scriptlet code, custom tags add an entirely new layer to the architectural
picture and require a strictly defined set of classes and descriptor files to operate.
20 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 20

While a detailed description of the steps required to create custom tags is beyond the
scope of this text, it is instructive to review the key concepts to frame the recommen-
dations we will be making.
Custom Tag Key Concepts
Custom tags require a minimum of three components:
■■ The Tag Handler Class is a Java class implementing either the javax.servlet
.jsp.tagext.Tag or BodyTag interfaces. The Tag Handler Class defines the
behavior of the tag when invoked in the JSP page by providing set methods for
attributes and implementations for key methods such as doStartTag() and
doEndTag().
■■ The Tag Library Descriptor (TLD) File contains XML elements that map the tag
name to the Tag Handler Class and provide additional information about the
tag. This file defines whether the tag contains and manipulates JSP body con-
tent, whether it uses a Tag Extra Information (TEI) class, and the name of the
library containing this tag.
■■ JSP Pages contain <%@ taglib ... %> declarations for the tag library and
individual tag elements in the page itself to invoke the methods contained in
the Tag Handler Class.
Custom tags may also define a Tag Extra Information (TEI) class, extending
javax.servlet.jsp.tagext.TagExtraInfo, that defines the tag interface in
detail and provides the names and types of scriptlet variables introduced by the tag.
During page generation, the JSP engine uses the TEI class to validate the tags embed-
ded on the page and include the correct Java code in the servlet to introduce scriptlet
variables defined by the custom tag.
Custom Tag Use Is Easy—Development Is Complex
It is important to keep the appropriate goal firmly in mind when evaluating a new
technology or feature for potential use on your project. In the case of jsp:useBean
elements or custom tags, the goal is normally to improve the readability and maintain-
ability of the JSP pages. The assumption is that by reducing or eliminating scriptlet
code the page will be easier to understand and maintain, which is true enough. But the
JSP pages are only one part of the total system being developed. The beans and custom
tags are part of the system as well, and any improvement in maintainability of the JSP
pages must be weighed against the complexity and maintenance requirements of the
beans and tags themselves.
Custom tag development, in particular, is complex. The complexity is not evident
until the tasks being performed become more realistic, perhaps requiring TEI classes,
body content manipulation, handling of nested tags, or other more advanced behav-
iors. Examine the source code for some tag libraries available in the open-source com-
munity (see the libraries in http://jakarta.apache.org/taglibs, for example) to get a
sense of the requirements for a realistic, production-ready tag library. Is your develop-
ment team ready to tackle this level of development? Are the people being earmarked
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 21

for maintenance of the application capable of maintaining, extending, or debugging
problems in the tag library? These are valid questions you should consider when mak-
ing your decision to build a custom tag library.
Using custom tags, on the other hand, is relatively easy. It requires a simple declara-
tion at the top of the JSP page and a few straightforward XML elements in the page to
invoke the custom tag and produce the desired behavior. Although there may be cases
when scriptlet code is still the appropriate solution, we recommend using custom tags
for most development efforts.
In the end, the decision comes down to the benefits of using custom tags versus the
effort to develop and maintain the custom tags. Clearly a tag that is developed once
and used on many pages may pay for itself through the incremental benefits accrued
across multiple uses. Taken to the limit, the most benefit will come from a tag used in
many pages that is acquired rather than internally developed, eliminating all develop-
ment and maintenance effort on the tag itself. This should be your goal: Use custom
tags, but don’t develop them.
BEST PRACTICE Custom tags are easy to use but difficult to develop and
maintain, so make every effort to locate and use existing tag libraries from
reputable sources rather than developing your own custom tags.
Many useful tag libraries are available from various vendors and open-source
communities. Table 1.4 provides a short list to get you started in your search.
Table 1.4 Custom Tag Sources
LOCATION DESCRIPTION
http://jakarta.apache.org/taglibs This source has a large number of
open-source tag libraries,
providing everything from string
manipulation to regular-
expression handling to database
access.
http://jakarta.apache.org/struts Struts is a model-view-controller
framework that includes a
number of useful tag libraries.
http://www.servletsuite.com/jsp.htm This commercial vendor, with
more than 80 different tag
libraries, offers free binary
download and evaluation.
http://www.sourceforge.net/projects/jsptags This source has open-source tag
libraries created by members of
the SourceForge community.
Many different libraries and
functions are included.
http://www.jsptags.com This is a good reference site that
lists many available tag libraries.
22 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 22

In addition, BEA packages a few custom tags in the WebLogic Server product,
including a very useful caching tag we will examine in the next section.
We will be using selected custom tags from the Struts framework in the example
application in Chapters 3 and 4 to display bean data and create HTML form elements
with automatic handling of posted data during processing.
Cache Page Output to Improve Performance
Caching is a time-honored mechanism to improve performance. Database products
use caching to improve throughput, application servers use caching to improve EJB
performance, and many applications include caching in the business or services layer
to avoid costly calculations or data access. All of these layers of caching are important,
but in a Web application the surest way to improve performance is to cache the page
output itself whenever possible because caching page output can completely eliminate
calls to the business services and data-access routines.
Custom tags provide a powerful mechanism for caching page output because tags
are allowed to access and modify the content placed in their body and skip the pro-
cessing of that body content during subsequent invocations. In other words, a properly
designed custom tag can “surround” a section of page output, allow the page to
process normally the first time, store the generated HTML response, and use the stored
response instead of processing the content for subsequent requests.
WebLogic Server includes a caching custom tag called wl:cache in the weblogic-
tags tag library. This tag can cache page output based on any key value in the session,
request, page, or application scope, can cache at any one of these scopes, and can be set
to cache for a limited or indefinite time. Caching is performed using Java system mem-
ory for maximum performance, unlike some open-source page-caching tags that use
disk storage.
Some simple examples will show you how the wl:cache custom tag works. The
format for the wl:cache tag, when used to cache output, is this:
<wl:cache name=”...” key=”...” scope=”...” timeout=”...” size=”...”>
...
// Body content to be cached..
// Can be HTML, JSP scriptlets, directives, other tags, etc.
...
</wl:cache>
In the simplest form, with no key or scope information supplied in the attributes, the
wl:cache tag caches the generated body content for the specified length of time for all
clients (because application scope is default):
<wl:cache timeout=”60s”>
...
// Body content to be cached..
...
</wl:cache>
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 23

Listing 1.5 shows the CacheTest1.jsp example program that demonstrates the
use of the caching tag in this simple manner. The content above the wl:cache tag is
evaluated with every page invocation, but the content in the tag is evaluated the first
time the page is accessed by any user and cached for 60 seconds.
<%@ taglib uri=”weblogic-tags.tld” prefix=”wl” %>
<HTML>
<BODY>
Current time is: <%= System.currentTimeMillis() %><br>
<wl:cache timeout=”60s”>
<% System.out.println(“Inside cached body”); %>
Cached time is: <%= System.currentTimeMillis() %><br>
</wl:cache>
</BODY>
</HTML>
Listing 1.5 CacheTest1.jsp.
Accessing this JSP page repeatedly will produce browser output similar to the
following:
Current time is: 1015363376897
Cached time is: 1015363376897
Current time is: 1015363385004
Cached time is: 1015363376897
...
The displayed cached time will remain unchanged in the output during subsequent
page hits because the contents of the body, including the call to System.current-
TimeMillis(), are not evaluated in the generated servlet. The System.out
.println() log message in the body content will help confirm that the body is not
evaluated on subsequent invocations. After 60 seconds, the cache will expire, the body
content will be evaluated during the next page request, and the cached HTML
response will be updated with the new output.
Even this simple behavior might be useful in a real application because the
wl:cache tag can wrap any arbitrary JSP content, even directives such as
jsp:include. Recall that jsp:include is used to include content generated by
other JSP pages within the current page at page-processing time, often as an alternative
to the page-generation-time <%@ include file=”...” %> directive. If your dis-
play pages are built up from multiple component parts (header, footer, navigation bars,
etc.) using many separate jsp:include directives to include the parts, a simple
wl:cache tag placed around these directives can dramatically improve performance.
The CacheTest2.jsp example program in Listing 1.6 illustrates this technique.
24 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 24

<HTML>
<BODY>
<wl:cache timeout=”5m”>
<TABLE BORDER=”1”>
<TR>
<TD><jsp:include page=”CacheTest2_header.jsp”/></TD>
</TR>
<TR>
<TD><jsp:include page=”CacheTest2_navbar.jsp”/></TD>
</TR>
<TR>
<TD>
<TABLE BORDER=”1”>
<TR>
<TD><jsp:include page=”CacheTest2_leftside.jsp”/></TD>
</wl:cache>
<TD>This is the main content for the page..</TD>
<wl:cache timeout=”5m”>
<TD><jsp:include page=”CacheTest2_rightside.jsp”/></TD>
</TR>
</TABLE>
</TD>
</TR>
<TR>
<TD><jsp:include page=”CacheTest2_footer.jsp”/></TD>
</TR>
</TABLE>
</wl:cache>
</BODY>
</HTML>
The first time this page is executed, the HTML response generated by the content in
the sets of wl:cache tags will be cached in memory. Subsequent page requests will
avoid the multiple jsp:include operations during the page processing and the per-
formance hit that goes with them.
BEST PRACTICE Look for opportunities to cache static, or relatively static,
content using the wl:cache custom tag. Caching the results of jsp:include
operations can improve performance significantly.
The first two example programs limited themselves to key-less caching, meaning that
the content was cached and reused for the specified period of time regardless of client
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 25

identity, or any parameter or value present during the page processing. In most cases,
however, the generated page content depends on some contextual information such as
a request parameter or scriptlet variable. Fortunately, the wl:cache tag includes a
powerful and flexible mechanism for caching content based on parameters and other
context information through the key attribute in the wl:cache tag definition:
<wl:cache key=”[parameter|page|session|request|application].keyname” ...>
The important assumption is that the body content depends on the value of the key
or keys, so caching must also depend on these values. For example, if the body content
depends on the value of a request parameter called howmany, the wl:cache tag must
include this parameter in the key attribute. The CacheTest3.jsp example program
in Listing 1.7 illustrates this case.
<HTML>
<BODY>
<wl:cache name=”CacheTest3” key=”parameter.howmany” timeout=”5m”>
<%
int jj = Integer.parseInt(request.getParameter(“howmany”));
System.out.println(“Inside cached body with howmany of “ + jj);
%>
<H2>We’re going to count from 1 to <%= jj %><H2>
<%
for (int ii = 1; ii <= jj; ii++) {
out.print(ii + “<br>”);
}
%>
</wl:cache>
</BODY>
</HTML>
Accessing this page with a specific value of howmany in the query string causes the
body content, including the loop and System.out.println() code, to be executed
one time. Subsequent page hits with the same howmany parameter value return the
same content without reevaluating the content. Supplying a different value for how-
many will cause the body to be evaluated for that value and the contents cached using
that key value. In other words, if you hit the page five times with different howmany val-
ues, you’ve created five different cached versions of the body content using howmany as
the key. This technique is very slick and very powerful for improving site performance.
Two of the optional attributes in the wl:cache tag provide important capabilities:
■■ The size attribute limits the size of the cache to a certain value. If the cache is
key dependent and there are many possible key values, it is a good idea to limit
the size of the cache to something reasonable (perhaps 500 to 1,000 entries)
using this attribute.
26 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 26

■■ The name attribute is used to identify this cache within the overall set of caches
managed by the wl:cache tag library. If you omit this attribute, the name will
be a unique combination of the request URI and tag index in the page. This
may be sufficient in simple cases. If the cache must be flushed, however, a
name should be specified to allow a different wl:cache tag to be able to refer
to the same name and flush the cache.
Content that depends on multiple parameters or context values can be cached by
combining the parameters in the key attribute using a comma separator or by com-
bining the multiple values ahead of time in a single scriptlet variable and placing that
variable in the key attribute using the page.varname syntax. This code snippet uses
multiple key parts:
<wl:cache key=”parameter.howmany,parameter.color” timeout=”5m”>
...
</wl:cache>
This is effectively the same as this snippet:
<%
String ss = request.getParameter(“howmany”) + “,” +
request.getParameter(“color”);
%>
<wl:cache key=”page.ss” timeout=”5m”>
...
</wl:cache>
In both cases, the content is cached and reused depending on the value of both the
howmany and color request parameters.
How would caching work in a real application that displays business information
using something like entity beans or value objects retrieved from a stateless session
bean, two architectures common in J2EE applications? The JSP page used to display the
bean content places the content-generation code in a wl:cache tag that depends on
the value of the primary key for the bean. Subsequent page hits for the same bean
information will then use the cached content.
The trick, of course, is that the underlying bean data may change, and the cached
display page will continue to use the cached HTML output for that particular bean
until the time-out period expires. You need to be able to flush the cache for a particular
key value when the content is no longer valid in order to force the next page request to
retrieve the bean and display the latest data. The wl:cache tag includes an optional
attribute called flush for this purpose. You would flush the cache used by
CacheTest3.jsp, for example, using a tag like this:
<wl:cache name=”CacheTest3” key=”parameter.howmany” flush=”true” />
Note that there can be no body content when the wl:cache tag is used to flush a
cache.
Generally speaking, this tag should be executed immediately after the bean is
updated in the database. As we will discuss in Chapter 2, most large Web applications
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 27

use servlets rather than JSP pages for processing bean changes. It is awkward, if not
impossible, to call a JSP custom tag within a servlet to perform an activity like flushing
the cached content for this particular bean.
One reasonable solution is to include logic in the display JSP page to sense a partic-
ular flushcache request parameter and conditionally perform the flush early in the
processing of the page if this parameter is present. The servlet that performed the bean
update will normally forward processing to the display JSP page after completing the
update, and it is easy enough to include the flushcache parameter in the request
before forwarding.
BEST PRACTICE Use the key-specific caching capability of the wl:cache
custom tag to cache page content for specific request parameters and beans
whenever possible.
Use Servlet Filtering for Common Behaviors
Servlet filtering, a new feature of servlets introduced in the Servlet 2.3 specification,
provides a declarative technique for intercepting HTTP requests and performing any
desired preprocessing or conditional logic before the request is passed on to the final
target JSP page or servlet. Filters are very useful for implementing common behaviors
such as caching page output, logging page requests, providing debugging information
during testing, and checking security information and forwarding to login pages. Fig-
ure 1.2 illustrates the basic components of the filtering approach and shows the incom-
ing HTTP request passing through one or more Filter classes in the FilterChain
collection defined for this page request.
Placing a filter in the path of a particular servlet or JSP request is a simple two-step
process: Build a class that implements the javax.servlet.Filter interface, and
register that class as a filter for the desired pages and servlets using entries in the
web.xml descriptor file. To illustrate this process, we will build and deploy a simple
but useful filter that intercepts servlet and JSP requests and logs HttpServlet
Request information before passing the request on to the intended JSP page or
servlet. We’ll call the filter SnoopFilter because it is very similar to the
SnoopServlet discussed previously.
Figure 1.2 Servlet filtering.
HTTP Request
HTTP Response
Filter1
Filter Chain
Filter1
Servlet
28 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 28

Building a Simple SnoopFilter Filter Class
The first step is the construction of a filter class called SnoopFilter that implements
the javax.servlet.Filter interface and performs the desired logging of request
information. Simply put, the doFilter() method writes information from the
HttpServletRequest object to System.out before forwarding to any additional
filters in the filter chain. The source for SnoopFilter is available from the companion
Web site (http://www.wiley.com/compbooks/masteringweblogic).
Registering SnoopFilter in the web.xml Descriptor File
Registering a filter requires a set of elements in the Web application descriptor file,
web.xml. These elements declare the filter class and define the pages or servlets to
which the filter should be applied. In this simple example, you want all pages and
servlets in the application to be filtered through SnoopFilter, and the web.xml file
includes the following elements:
<filter>
<filter-name>SnoopFilter</filter-name>
<display-name>SnoopFilter</display-name>
<description></description>
<filter-class>
mastering.weblogic.ch01.example1.SnoopFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>SnoopFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
The <url-pattern>/*</url-pattern> element declares that all pages and
servlets in the application should be filtered using SnoopFilter, so every page
request will go through the filter before normal processing begins. The server’s stdout
stream will therefore contain detailed request information for every page request,
which is potentially very useful during development and debugging.
Clearly the same general logging capability could have been placed in a helper class,
custom tag, or simple scriptlet included in each JSP page or servlet, but the ability to
control the specific pages or groups of pages using the SnoopFilter in a declarative
manner (via url-pattern elements) has significant advantages.
Although this is obviously a simple example, SnoopFilter illustrates the value of
filters for preprocessing activities such as logging, auditing, or debugging in J2EE Web
applications. Filters are not limited to writing output to stdout; they can easily write
information to separate log files, insert rows in database tables, call EJB components,
add or modify request attributes, forward the page request to a different Web applica-
tion component, or perform any other desired behavior unconditionally or based on
specific request information. They are a very powerful addition to the J2EE servlet
specification.
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 29

BEST PRACTICE Use filters to implement common behaviors such as
logging, auditing, and security verification for servlets and JSP pages in your
Web applications.
Response Caching Using the CacheFilter
WebLogic Server includes a filter called CacheFilter that provides page-level
response caching for Web applications. This filter is very similar to the wl:cache cus-
tom tag, discussed earlier in this chapter, except that it operates at the complete page
level rather than surrounding and caching only a section of JSP content in a page. The
CacheFilter may also be used with servlets and static content, unlike the custom
tag, which works only for JSP pages.
The CacheFilter is registered like any other servlet filter. Define the filter in the
web.xml file, and specify the url-pattern of the page or pages to cache. Use initial-
ization parameters in the filter registration to define time-out criteria and other cache
control values similar to the wl:cache custom tag. For example, to cache the response
from a specific JSP page for 60 seconds, register the CacheFilter using elements
similar to the following:
<filter>
<filter-name>CacheFilter1</filter-name>
<filter-class>weblogic.cache.filter.CacheFilter</filter-class>
<init-param>
<param-name>timeout</param-name>
<param-value>60</param-value>
</init-param>
</filter>
...
<filter-mapping>
<url-pattern>CacheFilterTest1.jsp</url-pattern>
</filter-mapping>
The JSP page will execute the first time the URL is accessed by any client, and the
content of the HTTP response will be cached by the filter and used for all subsequent
access requests for 60 seconds.
Additional initialization parameters for the CacheFilter include the following:
Name. The name of the cache. The wl:cache tag may be used to flush the
CacheFilter cache using this name and the flush=”true” attribute. It
defaults to the request URI.
Timeout. Timeout period for the cached content. It defaults to seconds, but it
may be specified in units of ms (milliseconds), s (seconds), m (minutes), h
(hours), or d (days).
Scope. The scope of the cached content. Valid values are request, session, appli-
cation, and cluster. Note that CacheFilter does not support page scope. It
defaults to application scope.
30 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 30

Key. The name of request parameters, session attributes, and other variables
used to differentiate cached content. It is similar in function to the key attribute
in the wl:cache custom tag.
Size. The maximum number of unique cache entries based on key values. It
defaults to unlimited.
As a final example, recall that the CacheTest3.jsp page examined earlier used
the wl:cache tag to cache the generated content based on the howmany request
parameter because the page response depended on the value of that parameter (see
Listing 1.7). The equivalent CacheFilter implementation would require the follow-
ing entries in the web.xml file:
<filter>
<filter-class>weblogic.cache.filter.CacheFilter</filter-class>
<init-param>
<param-name>timeout</param-name>
<param-value>5m</param-value>
</init-param>
<init-param>
<param-name>key</param-name>
<param-value>parameter.howmany</param-value>
</init-param>
</filter>
...
<filter-mapping>
<url-pattern>CacheFilterTest3.jsp</url-pattern>
</filter-mapping>
The key parameter indicates that the page-level cache should be segregated based
on the value of the howmany parameter in the request. A separate cached response will
be created for each value of this parameter and used for five minutes before reevaluat-
ing the underlying page. Note that the CacheFilter class must be registered using a
different filter-name element each time in order to supply different initialization
parameters. The CacheFilterTest3.jsp page is very similar to CacheTest3.jsp
(Listing 1.7), but it no longer requires the wl:cache custom tags:
<HTML>
<BODY>
<%
int jj = Integer.parseInt(request.getParameter(“howmany”));
System.out.println(“Inside cached body with howmany of “ + jj);
%>
<H2>We’re going to count from 1 to <%= jj %><H2>
<%
for (int ii = 1; ii <= jj; ii++) {
out.print(ii + “<br>”);
}
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 31

%>
</BODY>
</HTML>
The CacheFilter approach has an obvious advantage over the wl:cache
technique in this example: Caching is performed using a declarative technique rather
than embedding custom tags in the page itself. This defers the definition of caching
behavior to deployment time and allows easier control of the caching parameters and
scope using the web.xml descriptor elements.
BEST PRACTICE Use the CacheFilter instead of wl:cache tags for page-
level response caching whenever possible to provide better flexibility during
deployment.
Note that a JSP page included using the jsp:include element is considered a
separate page for the purposes of caching. Configuring the CacheFilter to cache the
contents of the included JSP page represents a viable alternative to surrounding the
jsp:include element with wl:cache tags.
Using Custom JSP Base Classes
Recall that JSP pages are processed by the JSP engine and converted to a servlet. In
WebLogic Server, the resulting servlet is a subclass of weblogic.servlet
.jsp.JspBase by default. JspBase is a WebLogic-provided class that extends
HttpServlet and forwards service calls to a method called _jspService(). You
may create your own custom JSP base class that extends JspBase and configure the
JSP engine to use your base class for generated servlets by including the extends
attribute in the <%@ page ... %> directive on the JSP page.
The ability to define a custom JSP base class provides an alternative to static
include directives for defining helper functions and utilities in the page. For exam-
ple, if you want to provide a simple helper method called formatDate() to format a
java.util.Date object, the method should probably be placed in a custom JSP base
class rather than defining it in a separate file included using the <%@ include
file=”...” %> directive.
Using Run-Time Expressions in JSP Directives
Most of the attributes in JSP directives may be set using static information or using the
contents of scriptlet expressions at run time. For example, the following simple
jsp:include directive uses a statically defined target page:
<jsp:include page=”welcome.jsp” />
The following version of the directive uses the value of the scriptlet variable mypage
to determine which page to include at run time:
<jsp:include page=”<%= mypage %>” />
32 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 32

The syntax used in these dynamic expressions is very similar to the normal use of
the <%= %> expression scriptlets used to generate content in the HTTP response
with one notable exception: The parser cannot handle expressions with unescaped
double quotes. For example, the following directive will fail during page parsing and
compilation:
<jsp:include page=”<%= mypage + “.jsp” %>” />
The expression should be written this way using escaped double quotes:
<jsp:include page=”<%= mypage + ”.jsp” %>” />
If this becomes too confusing for complex expressions, simply create a temporary
scriptlet variable before the directive and refer to that variable in the directive, as
shown here:
<% String fullname = mypage + “.jsp”; %>
<jsp:include page=”<%= fullname %>” />
The example application built in Chapters 3 and 4 will make use of run-time expres-
sions in jsp:include directives as part of its page-presentation architecture.
Creating Excel Files Using Servlets and JSP Pages
Creating spreadsheets using servlets and JSP pages is a useful way to provide users
with results they can sort, manipulate, and print using Microsoft Excel or other spread-
sheet applications. Servlets are the preferred mechanism, but JSP pages can also be
used if you take steps to avoid unintended newline characters in the output stream.
To create a spreadsheet using a servlet, build the servlet in the normal manner but
set the content type to application/vnd.ms-excel in the response header to indi-
cate that the response should be interpreted as a spreadsheet. Data written to the
response Writer object will be interpreted as spreadsheet data, with tabs indicating
column divisions and newline characters indicating row divisions. For example, the
SimpleExcelServlet servlet in Listing 1.8 creates a multiplication table using sim-
ple tabs and newlines to control the rows and columns in the result.
package mastering.weblogic.ch01.example1;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class SimpleExcelServlet extends HttpServlet
{
public static final String CONTENT_TYPE_EXCEL =
Listing 1.8 SimpleExcelServlet.java. (continued)
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 33

“application/vnd.ms-excel”;
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException
{
PrintWriter out = response.getWriter();
response.setContentType(CONTENT_TYPE_EXCEL);
out.print(“t”); // empty cell in upper corner
for (int jj = 1; jj <= 10; jj++) {
out.print(“” + jj + “t”);
}
out.print(“n”);
for (int ii = 1; ii <= 10; ii++) {
out.print(“” + ii + “t”);
for (int jj = 1; jj <= 10; jj++) {
out.print(“” + (ii * jj) + “t”);
}
out.print(“n”);
}
}
}
Normal registration of this servlet in web.xml is all that is required in most cases:
<servlet>
<servlet-name>SimpleExcelServlet</servlet-name>
<servlet-class>
mastering.weblogic.ch01.example1.SimpleExcelServlet
</servlet-class>
</servlet>
<servlet-mapping>
<url-pattern>/SimpleExcelServlet</url-pattern>
</servlet-mapping>
Users accessing the /SimpleExcelServlet location will be presented with a
spreadsheet embedded in their browser window. The servlet may also be registered for
a url-pattern that includes a .xls file extension to assist the user by providing a
suitable default file name and type if they choose to use Save As... from within the
browser:
<servlet-mapping>
34 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 34

<url-pattern>/multitable.xls</url-pattern>
</servlet-mapping>
Simple tab- and newline-based formatting may be sufficient in many cases, but you
can achieve additional control by building HTML tables and using HTML formatting
options such as <b> and <i> in the generated output. Because the content type was
specified as ms-excel, these HTML tags are interpreted by the browser and spread-
sheet application as equivalent spreadsheet formatting options.
The FancyExcelServlet example servlet in Listing 1.9 builds the same multipli-
cation table as SimpleExcelServlet but uses HTML to control formats and cell sizes.
package mastering.weblogic.ch01.example1;
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class FancyExcelServlet extends HttpServlet
{
public static final String CONTENT_TYPE_EXCEL =
“application/vnd.ms-excel”;
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException
{
PrintWriter out = response.getWriter();
response.setContentType(CONTENT_TYPE_EXCEL);
out.print(“<table border=1>”);
out.print(“<tr>”);
out.print(“<td> </td>”); // empty cell in upper corner
for (int jj = 1; jj <= 10; jj++) {
out.print(“<td><b>” + jj + “</b></td>”);
}
out.print(“</tr>”);
for (int ii = 1; ii <= 10; ii++) {
out.print(“<tr>”);
out.print(“<td><b>” + ii + “</b></td>”);
for (int jj = 1; jj <= 10; jj++) {
out.print(“<td>” + (ii * jj) + “</td>”);
}
out.print(“</tr>”);
}
out.print(“</table>”);
}
}
Listing 1.9 FancyExcelServlet.java.
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 35

You can also use JSP pages to create spreadsheets with one complication: The output
of a JSP page often contains many spurious newline characters caused by extra white-
space around directives and scriptlet tags, making it difficult to control the spreadsheet
formatting when using simple tab and newline techniques. HTML formatting similar
to the FancyExcelServlet works better in JSP pages used to create spreadsheets.
Listing 1.10 presents the JSP equivalent to the FancyExcelServlet.
<% response.setContentType(“application/vnd.ms-excel”); %>
<html>
<body>
<table border=1>
<tr>
<td> </td>
<% for (int jj = 1; jj <= 10; jj++) { %>
<td><b><%= jj %></b></td>
<% } %>
</tr>
<% for (int ii = 1; ii <= 10; ii++) { %>
<tr>
<td><b><%= ii %></b></td>
<% for (int jj = 1; jj <= 10; jj++) { %>
<td><%= (ii * jj) %></td>
<% } %>
</tr>
<% } %>
</table>
</body>
</html>
Listing 1.10 FancyExcelPage.jsp.
Viewing Generated Servlet Code
Viewing the servlet code generated for a particular JSP page can be instructive while
learning JSP technology and useful during the testing and debugging process. Often
the error report received during the execution of the JSP page indicates the line in the
generated servlet code, but finding the JSP scriptlet code or tag that caused the error
requires inspection of the Java code.
Generated Java servlet code will be kept alongside the generated servlet class files if
the keepgenerated parameter is set to true in the jsp-descriptor section of the
weblogic.xml descriptor file. The equivalent option for keeping the generated Java
code for JSP pages compiled using the weblogic.jspc utility is -keepgenerated
placed on the command line used to execute weblogic.jspc.
By default, the generated servlet classes and Java code will be placed in a temporary
directory structure located under the domain root directory. The name of this tempo-
rary directory depends on the names of the server, enterprise application, and Web
36 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 36

application, and it typically looks something like /myserver/.wlnotdelete
/_appsdir_masterapp_dir_webapp_myserver/jsp_servlet. This default
location may be overridden using the workingDir option in the weblogic.xml
descriptor file.
Programmatic Authentication in Web Applications
The J2EE specification provides a declarative mechanism for controlling access to
resources in the Web application. This mechanism uses elements in the web.xml file to
define collections of resources and specify the roles required to access these resources.
Users are asked for their logon identifier and password via a pop-up HTTP challenge
window or special form configured for this purpose; upon submission of valid creden-
tials, the user will be authenticated in the Web application security context and will be
able to access secured resources. Chapter 10 of this book will cover many different
aspects of WebLogic Server security including this simple declarative security for Web
applications.
This declarative mechanism can occasionally fall short of the desired functionality,
and many developers have resorted to building their own authorization mechanisms.
In many of these designs the users are never actually authenticated in the Web appli-
cation security context, and access to business-tier resources like EJB components is
accomplished through the default, or <anonymous>, user. This is a poor practice for at
least two reasons:
■■ Anyone with knowledge of the server listening port can connect to WebLogic
Server as the <anonymous> user and gain access to the EJB components.
■■ The Web application does not forward a useful security context to the EJB con-
tainer, thereby eliminating the value of methods such as
getCallerPrincipal() and isCallerInRole() in the EJB components
for security and auditing purposes.
WebLogic Server provides a little-known interface to programmatically authenticate
the user and establish a proper security context for this client in the Web application. The
method is located in the weblogic.servlet.security.ServletAuthentication
class and is called simply weak(). The example page shown in Listing 1.11 takes
parameters passed in through the HttpServletRequest and authenticates the user
using the weak() method.
<%@ page import=”weblogic.servlet.security.ServletAuthentication” %>
<HTML>
<HEAD>
<TITLE>Login Tester JSP Page</TITLE>
</HEAD>
<BODY>
<H2>User name before login is:
Listing 1.11 WeakLoginTest.jsp. (continued)
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 37

<%= weblogic.security.acl.Security.getThreadCurrentUserName() %>
</H2>
<%
// logs out if already logged in
ServletAuthentication.logout(request);
String username = request.getParameter(“username”);
String password = request.getParameter(“password”);
int retcode = ServletAuthentication.weak(username,
password, session);
if (retcode == ServletAuthentication.AUTHENTICATED) {
out.print(“Successful login using “ +
username + “ and “ + password + “.<br>”);
}
else {
out.print(“Bad login/password.<br>”);
}
%>
<H2>User name after login is:
<%= weblogic.security.acl.Security.getThreadCurrentUserName() %>
</H2>
</BODY>
</HTML>
Subsequent page requests by the same client will continue to use this newly estab-
lished security context, and any communication with the EJB container will pass this
context information along and make it available via getCallerPrincipal() or
other normal methods.
Chapter Review
In this chapter we reviewed the key concepts related to Web applications in WebLogic
Server and presented a number of important best practices designed to improve the
quality and performance of your Web applications.
Most of this chapter has been at the detailed design and implementation level, the
trees in a sense. In the next two chapters we will step back and look at the forest for a
few minutes by examining the importance of the overall Web application architecture,
the selection of a suitable presentation template technique, and the application of a
model-view-controller pattern and framework for form and navigation handling.
38 Chapter 1
01 28128x Ch01.qxd 7/29/03 8:45 AM Page 38

Weblogic

Recommended

More Related Content

What's hot (20)

Similar to Weblogic (20)

Recently uploaded (20)

Weblogic