JavaServer Pages (JSP) is the latest tool for Java-based Web application
development. A JSP page contains regular markup code plus special JSP
elements. When the page is requested, the static markup code and the
dynamic content produced by the JSP elements are combined to form the
complete response to the request.
It's impossible to tell you everything you need to know to use JSP
effectively in a short article like this (that's why I wrote
JavaServer Pages).
Instead, this article focuses on the frequently asked questions that I've
heard from people who have just started to play around with JSP.
- Choosing the Right Include Mechanism
A JSP page can include page fragments from other files to form the complete
response. You can use this, for instance, to keep header, footer, and
navigation bar content in separate files and include them in all other
pages. There are two include mechanisms: the include directive and
the include action. It's not always obvious which one to use,
though.
The include directive, <%@ include file="filename.inc" %>,
includes the content of the specified file during the translation
phase--when the page is converted to a servlet. The main page and the
included file are simply merged. This means that scripting variables
declared in one file (using scripting elements or an action element like
<jsp:useBean>) are visible in all files and must have unique
names. Some containers detect changes in files included with the directive,
but the specification doesn't require it. Therefore, changes you make to
the included file in a running system may not be reflected immediately; you
may have to update the main JSP page, or remove the class file generated
for the main page in order to see the change.
The include action,
<jsp:include page="pagename.jsp" flush="true" />,
includes the response generated by executing the specified page (a
JSP page or a servlet) during the request processing phase--when the page
is requested by a user. As opposed to the include directive, the page name
can be specified as a so-called request-time attribute value, so
which page to include can be decided when the main page is requested. Since
it's the response generated by the page that is included, not the
content of the page itself, scripting variables declared in one file are
not available to the other files. To share an object between the pages you
must instead place it in one of the following JSP scopes: request, session
or application scope. If you change a page included with the include
action, the change always takes effect immediately.
My rule of thumb for when to use the different mechanisms is this:- Use the include directive if the file changes rarely. It's the
fastest mechanism. If your container doesn't automatically detect changes,
you can force the changes to take effect by deleting the main page class
file. - Use the include action only for content that changes often, and
if which page to include cannot be decided until the main page is requested.
- Use the include directive if the file changes rarely. It's the
- Dealing with Buffer Flushing Issues
An HTTP response message contains both headers and a body. The headers tell
the browser things like what type of data the body contains (HTML text, an
image), the size of the body, if the body can be cached, and so on. Headers
are also used to set cookies and to tell the browser to automatically get
another page (a redirect). All response headers must be sent to the browser
before the body is sent.
To allow parts of the body to be produced (from static template text as
well as content generated dynamically by JSP elements) before headers are
set, the body is buffered. Instead of sending the response to the browser
as soon as something is written to the response body, the JSP container
writes all static markup code and all dynamic content generated by JSP
elements to the buffer. At some point, such as when the buffer is full or
the end of the page is reached, the container sends all headers that have
been set followed by the buffered body content. In servlet speak, this is
called committing the response. After the response has been
committed, you can't set headers, such as for cookies or a redirection
instruction. Another thing you can't do is forward the request to another
page.
In most cases, this is not a problem. The default buffer size is 8KB, more
than enough for a typical page, and you can increase it with the
buffer attribute of the page directive. But if you use
the include action in a page, you may be in for a surprise. Due to
limitations in the way the servlet features used by
<jsp:include> are specified, the buffer is always flushed
before the target page is invoked. This means that you can't set headers or
use <jsp:forward> after a <jsp:include> action.
An unfortunate side-effect of this automatic flushing is that runtime
errors triggered by JSP elements after a <jsp:include> action
may not be reported correctly, since many JSP containers use the forward
mechanism to display the error page. If you see an error message like
"response already committed" in a page with <jsp:include>
elements, I suggest that you use the include directive instead (at least
until you have isolated the problem). - Passing Data Between Pages Processing the Same Request
Quite often, more than one JSP page is used to process a single request.
One example is when you use the include action to include a
common navigation bar in all pages. Another example is when you use one
page for request processing (e.g., input validation and database access) and
then use the forward action, <jsp:forward page="pagename.jsp"
/>, to let another page generate the response. There are two ways to
pass data from one page to another: using request parameters or request
attributes.
First of all, the page invoked using a <jsp:include> or
<jsp:forward> action has access to all HTTP request parameters
that were sent to the first page. In addition, you can specify new request
parameters using nested <jsp:param> actions:
<jsp:forward page="login.jsp">
<jsp:param name="errMsg"
value="The name or password is not valid" />
</jsp:forward>
The target page has access to the all request parameters the same way, no
matter if they are original or additional parameters.
Request parameters can only hold string values. If you need to pass an
object, say a UserInfoBean with various user information
properties, you need to pass it as a request attribute instead (or as a
session or application scope bean, but let's ignore that for now). A
request attribute is the same thing as a request scope object, so the first
page can create the object and set all its properties with the
<jsp:useBean> and <jsp:setProperty> actions:
<jsp:useBean id="userInfo" scope="request"
class="com.mycompany.UserInfoBean">
<jsp:setProperty name="userInfo" property="*" />
</jsp:useBean>
...
<jsp:forward page="nextpage.jsp" />
In order to use the bean in a page invoked through <jsp:forward>
or <jsp:include>, you must use the <jsp:useBean>
action in the invoked page as well. This is so that the bean created by the
first page can be located and associated with the specified id. It can then
be used by scripting code or other actions, such as
<jsp:getProperty>, in the new page:
<jsp:useBean id="userInfo" scope="request"
class="com.mycompany.UserInfoBean" />
<jsp:getProperty name="userInfo" property="firstName" /> - Choosing Between Forward and Redirect
If you want to pass the control from one page to another, you can either
forward to the other page, as described above, or redirect to
the new page (using the sendRedirect() method of the implicit
response object).
There's an important difference between a forward and a redirect. When you
forward, the target page is invoked by the JSP container through an
internal method call; the new page continues to process the same request
and the browser is not aware of the fact that more than one page is
involved. A redirect, on the other hand, means that the first page tells
the browser to make a new request to the target page. The URL shown in the
browser therefore changes to the URL of the new page when you redirect, but
stays unchanged when you use forward. A redirect is slower than a forward
because the browser has to make a new request. Another difference is that
request scope objects are no longer available after a redirect because it
results in a new request. If you need to pass data to the page you redirect
to, you have to use a query string and pass them as request parameters (or
save the data as session or application scope objects).
So how do you decide if you should use forward or redirect? I look at it
like this: Forwarding is always faster, so that's the first choice. But
since the URL in the browser refers to the start page even after the
forward, I ask myself what happens if the user reloads the page (or just
resizes the window; this often reloads the page automatically). If the
start page is a page that updates some information, such as adding an item
to the shopping cart or inserting information in a database, I don't want
it to be invoked again on a reload. To show the result of the processing,
I therefore redirect to a page with a confirmation message, instead of
using forward. - Choosing Between Beans and Custom Actions
In JSP 1.0, JavaBeans were the only type of components that you could use
to encapsulate the Java code and invoke using standard JSP action elements,
such as <jsp:getProperty> and <jsp:setProperty>.
JSP 1.1 adds custom action elements to the component toolbox. A
Java class, called a tag handler, implements a custom action's
behavior. In its most simple form, it's just a JavaBeans class with
property access methods corresponding to the custom action elements plus
a few extra methods used by the container to invoke the tag handler (so it
can do its job). Tag handlers that need to process the element's body or
create objects assigned to scripting variables requires a bit more effort
to develop, but it's still not rocket science. It is, however, too much to
describe in detail here. My book contains two chapters with all the
details about how to develop custom action tag handlers.
As is often the case in software development, it's hard to say exactly
when a bean or a custom action is the preferred component type. My rule of
thumb is that a bean is a great carrier of information and a custom
action is great for processing information. Custom actions can use
beans as input and output. For instance, you can use a bean to capture
form input, with the <jsp:setProperty> action, and then a
custom action to save the properties of the bean in a database. The
reverse is also a good example; get information from a database using a
custom action that makes it available to the page as a bean. - Using Packages for Bean Classes
When you develop a bean to be used in a JSP page, I recommend that you
make it part of a named package. A Java class that does not use a
package statement ends up in the so-called unnamed package.
The servlet class generated from the JSP page is, however, typically
assigned to a named package. If you try to refer to a class in the unnamed
package from a class in a named package, Java cannot find the class
unless you use an import statement to import it. In a JSP page that means
you must use both a page directive to import the class, and the
<jsp:useBean> action to make it available:
<%@ page import="UserInfoBean" %>
<jsp:useBean id="userInfo" class="UserInfoBean" />
If the bean is part of a named packed, the <jsp:useBean>
action is all you need:
<jsp:useBean id="userInfo"
class="com.mycompany.UserInfoBean" /> - Mixing Scripting Variables and Scope Variables
My general advice is that you avoid embedding Java code in your JSP pages.
Code in scripting elements can easily lead to hard to find syntax errors
and too much code in the pages makes the Web application hard to maintain.
One specific area of confusion when you use both Java code scriptlets and
JSP action elements is how scripting variables and objects created by an
action element in a JSP scope interact. Or rather, don't interact.
Consider this example:
<jsp:useBean id="userInfo"
class="com.mycompany.UserInfoBean" >
<jsp:setProperty name="userInfo" property="firstName" />
</jsp:useBean>
<%
userInfo = new com.mycompany.UserInfoBean();
%>
<jsp:getProperty name="userInfo" property="firstName" />
Here a UserInfoBean instance is created by the
<jsp:useBean> action in the page scope (default) and its
firstName property is set to the value passed as a request
parameter with the same name. The <jsp:useBean> also makes the
bean available as a scripting variable with the same name as the scope
variable (userInfo in this example). Next, a scriptlet creates a
new instance of the UserInfoBean class and assigns it to the
userInfo scripting variable. Finally, the
<jsp:getProperty> action retrieves the value of the bean's
firstName property. But which instance of the UserInfoBean
does <jsp:getProperty> use? The answer is the instance
available in the page scope. The <jsp:getProperty> action, or
any action element for that matter, cannot access scripting variables,
only objects placed in one of the standard JSP scopes: page, request,
session and application. If you must use scripting elements to create
objects that you then want to let actions access, you must also place them
in the appropriate scope:
...
<%
userInfo = new com.mycompany.UserInfoBean();
pageContext.setAttribute("userInfo", userInfo);
%>
<jsp:getProperty name="userInfo"
property="firstName" />
In this modified example, the setAttribute() method is used to
replace the page scope object created by <jsp:useBean> with
the instance created by the scriptlet. Hence, the
<jsp:getProperty> action finds the new instance. - Setting Properties to Non-String Data Type Values
Bean properties, as you probably know, are represented by accessor
methods: a setter method for a writeable property and a getter method for
a readable property. The data type of the property is the data type of the
setter method's single argument and the getter methods return type.
The <jsp:setProperty> action is often used to set a bean's
property to the values of request parameters. Request parameters are sent
as strings, so what happens if the bean's properties are of other types
than String? The JSP container is nice enough to convert
String values to the most commonly used Java data types, as
described in the following table:
Property TypeConversion Method
boolean or
BooleanBoolean.valueOf(String)
byte or ByteByte.valueOf(String)
char or
CharacterString.charAt(int)
double or
DoubleDouble.valueOf(String)
int or
IntegerInteger.valueOf(String)
float or
FloatFloat.valueOf(String)
long or LongLong.valueOf(String)
If your property is of a type not listed in the table, you need to take
care of the conversion yourself. The most author-friendly way is to use a
String property, even for properties that logically should be of a
different type, such as a date or a RGB color value, and let the bean
convert it internally. But if you really want to use a data type other
than String or the ones listed above, the page author can use a
request-time attribute value that evaluates to the correct data type to
set the property value:
<jsp:setProperty name="userInfo" property="empDate"
value='<%= new
java.util.Date(request.getParameter("empDate")) %>' />
Note that this example uses a deprecated Date constructor and is
very error-prone (it fails if the empDate parameter is missing or
doesn't hold a valid date string). I use it only to illustrate how you can
set an attribute of a data type that has no JSP-supported conversion rule,
such as the Date class used here.
The rules described here for bean properties set by
<jsp:setProperty> also applies to custom action attributes. - Accessing a Database
One of the most frequently asked questions on Sun Microsystem's JSP-INTEREST
mailing list is how to access a database from a JSP page. I'm sorry, but a
complete description is out of scope for this article. I can give you some
guidelines, though.
JSP is Java, so as in all Java programs, you'd use JDBC to access a database.
You can read more about the JDBC API here.
I recommend that you do not put the database access code directly
in the JSP page. Instead, create a bean or a custom action that does all
the hard work. My book contains a set of custom actions for database
access that you can use, and there are many other examples available on
the Net (see Tip 10 of this article). For a complex application,
you may actually want to use a servlet for all database access and let it
forward the request to a JSP page that only deals with rendering the
result. This model is often referred to as the Model-View-Controller (MVC)
model, or Model 2 (a term used in a prerelease of the JSP specification).
I show examples of this alternative in my book as well. You can also
learn more about the MVC model from the Apache Struts project.
Database access is typically very expensive in terms of server resources.
You should use a connection pool (covered in the book and frequently
discussed on the JSP-INTEREST list) to share database connections
efficiently between all requests. Another resource saver is to cache the
results of database queries as much as possible. In many cases, the
database information rarely changes. For instance, product catalog
information may change only when products are added or deleted, or when
the prices change. For this type of information you can get the data once
and save it as an application scope object that all users can access. In
the rare event that the information changes, just replace the application
scope object with a new version. Another caching strategy for data that
changes infrequently is to cache it as a session scope object. The user
will then see the data as it looks when the session starts, but changes
made during the session are not visible. If you use the session cache
strategy, you must also consider if the amount of memory used for the
cache (one copy per session) is worth the gain in reduced number of
database accesses. Typically it is worth it, but make sure your server has
enough memory to handle the peaks.
If you decide to use a cache, don't use the JDBC ResultSet object
itself as the cache object. A ResultSet is tightly linked to a
specific connection and therefore conflicts with the connection pooling.
Instead, copy the data from the ResultSet into an application
specific bean, a Vector of Vector's, or something
similar. - Finding Out More
I hope you have found something in this article that helps you develop
your JSP based application. But there's a lot more you should know to use
this powerful technology as efficiently as possible. I recommend, of
course, that you read my book,
JavaServer Pages
(O'Reilly).
There's also plenty of information on the Internet. The best place to
start Sun's JSP
page. There you find the JSP specification, articles and tutorials written
by Sun employees, and lots of references to other JSP-related sites and
products.
