??xml version="1.0" encoding="utf-8" standalone="yes"?>
]]>
2. Hessian
3. Burlap
4. HTTP invoker
5.
6. JAX-RPC
Java servlet technology provides developers with functionality, scalability, and portability that can't be found in other server-side languages. One feature of the Java servlet specification that's commonly used, and sometimes misused, is the HttpSession interface. This simple interface allows you to maintain a session or state for Web site visitors.
In my previous article ("Introduction to Session Management," [JDJ, Vol. 7, issue 9]), I introduced you to session management and the HttpSession interface. In that article, we walked through using the HttpSession API to create, use, and destroy session objects for Web site visitors. The next step is to better understand how to manage the sessions and those objects in a session. This article will help you achieve this by helping you understand the following concepts:
Listeners
A listener is an object that's
called when a specified event occurs. There are four listener
interfaces that allow you to monitor changes to sessions and the
objects that are in those sessions:
HttpSessionListener
The HttpSessionListener
interface is used to monitor when sessions are created and destroyed on
the application server. Its best practical use would be to track
session use statistics for a server.
The use of HttpSessionListener requires a configuration entry in the deployment descriptor, or web.xml file, of the application server. This entry points the server to a class that will be called when a session is created or destroyed. The entry required is simple. All you need is a listener and listener-class element in the following format. The listener-class element must be a fully qualified class name.
<listener>
<listener-class>package.Class</listener-class>
</listener>
As you can see in Figure 1, the class that implements this listener can override two methods: sessionCreated() and sessionDestroyed(). These methods will be notified when the server creates or destroys a session.
These methods take an HttpSessionEvent object as a parameter. HttpSessionEvent is simply a class that represents notifications of changes to the Web application's sessions. HttpSessionEvent has one method, getSession(), that returns the HttpSession object that's been modified.
HttpSessionBindingListener
The
HttpSessionBindingListener interface is implemented when an object
needs to be notified if it's being bound to a session or unbound from a
session.
This interface has two methods, valueBound() and valueUnbound(), that are notified when the status of the object has changed (see Figure 1).
These methods have an HttpSessionBindingEvent parameter that can be used to retrieve the session that the object was bound to and the name it was given in the session. In Figure 2, you can see the methods of this object that are used to get the name that's assigned to the object, the session it's bound to, and the actual object.
HttpSessionAttributeListener
The
HttpSessionAttributeListener interface is used to monitor changes to
attributes in any session on the server. This can be useful when you
know the name assigned to a specific object that gets put into the
session and you want to track how often it's being used.
As with HttpSessionListener, HttpSessionAttributeListener also requires an entry in the deployment descriptor for the server. This entry tells the server which class to call when an attribute in a session has changed.
The HttpSessionAttributeListener interface has three methods - attributeAdded(), attributeRemoved(), and attributeReplaced(). These methods, shown in Figure 1, are called by the server when attributes of a session are changed.
HttpSessionActivationListener
The final listener,
HttpSessionActivationListener, is implemented when an object needs to
know if the session that it's bound to is being activated or passivated
(moved). You would come across this scenario if your session is being
shared across JVMs or your server is persisting the session in a
database or file system.
This interface, displayed in Figure 1, has two methods that are overridden by the implementing class: sessionDidActivate() and sessionWillPassivate(). These methods are called when the status of the session in a JVM is changed.
Session Persistence
Today's J2EE-compliant
servers allow for fault-tolerance and failover to provide support in
the event that a server suddenly becomes unavailable because of
hardware, software, or network failure. This support is usually
provided by allowing two or more application servers, often called a
cluster, to run together and provide backup support for each other. If
one server fails, the others pick up the requests and continue on as if
nothing happened. This allows your Web site visitors to keep going
without interruption.
A proxy server is usually used in front of the application servers. This server is responsible for directing each HTTP request to the appropriate server. The proxy server can be set up to ensure that the server receiving the first request from a user will continue to receive all subsequent requests from that user. This means that a session created for the user on the application server will continue to be available for that user. If the server suddenly fails, there has to be a system in place to allow the session to continue on without it.
Session persistence allows the session contents to be saved outside the application server so that other servers can access it. Figure 3 shows the relationship between the persisted session data and the application servers that access it. In this figure, you see a client accessing a Web site's HTTP server. The HTTP server is forwarding requests for application resources to one of the application servers through the use of a proxy server. The application servers are persisting the session data in an external form.
There are four types of session persistence:
Memory Persistence
In most cases, a single
standalone server will store sessions in memory. This allows for fast
retrieval and update of the information. It also means that the session
information will be lost when the server is shut down. This is usually
the default configuration on most application servers. Memory
persistence can be used when two or more servers need to share the
session information. The application servers can be configured to share
any changes made to the session so that the information is available on
multiple servers. This redundancy of the session information helps the
cluster preserve the session during a failure.
File System Persistence
File system persistence
can be used to serialize any objects that are in the session. The
object contents are placed in a file on the server. The location of the
files created is configurable; however, the files must be accessible by
all the servers in the cluster. The speed at which the file system is
accessed can be a factor in the performance of your Web site. A slow
disk drive, for example, would result in a delay as data is read from
or written to the file.
Database Persistence
Database persistence can be
used to provide a central data store for the session contents. Each
application server in the cluster must be able to access the database.
When sessions are modified, the changes are immediately persisted in
the database. A data source is usually set up for JDBC persistence and
the connections are pooled. This provides a quicker response. There's
also the issue of database failover, which would be addressed at the
database level of the system.
Cookie Persistence
The fourth type of session
persistence, cookie persistence, is so ineffective and insecure that it
doesn't deserve consideration when designing a fail-safe system. Cookie
persistence, as the name implies, persists session data by storing the
session information in browser cookie(s). There's a limitation on data
handling because cookies store only text, not objects, and the amount
of data that can be transmitted in a cookie is limited. There's also
the fact that cookies transmit data back and forth between the client
and the server. This prevents you (at least it should) from saving
sensitive information, like a social security number. This type of
persistence should be used in only the smallest of Web sites, and only
if there's a good reason not to store the session in memory.
The most common type of persistence is database persistence. It provides an efficient way of saving session data and it's usually fairly easy to set up on the application server. Memory persistence in a cluster is also easy to use, if your application server supports it. The only drawback is that sessions can sometimes hold large amounts of data. Storing the session in memory reduces the amount of memory available to the other processes on the server. File system persistence can be slow at times and the file system may not always be accessible to multiple servers.
Watching the Session Size
As you and your
fellow employees work on a Web application, you may notice that more
and more objects are being thrown into the session, often "for
convenience" or "just temporarily." The session becomes a quick
catch-all for any information you need to get from your servlets to
your JSPs. The HttpSession interface makes sessions easy to use, which
can lead to the session being overused. This is a concern because the
session takes up space. In most cases that would be memory space. In
other cases, it could be database or file system space. In all cases,
it means more work for the server and more work for the programmers to
manage what is there.
Although the session is convenient because it's accessible from every servlet or JSP, it's not always the best place to put information. Most of the data that's retrieved for display in a Web application will only be used on one page. Instead of putting the information into the session scope, use the request scope and then forward the request from the servlet to the JSP. This causes the objects to be destroyed after the request has ended, which is after the data is displayed by the JSP. If you put the objects into the session, you would either have to remove them in your code or leave them there. Leaving objects in the session is not a good idea because you're using up valuable resources for no reason. This becomes even more of an issue when your Web site has hundreds or thousands of visitors, all of whom have a session that's loaded with objects.
Some objects should be stored in the session. Objects that may be needed over and over again as a user moves through a Web site are those that should be put into the session. Anything that needs to exist longer than one request can be stored in the session, as long as these objects are removed as soon as they're no longer needed.
Considerations for Managing Sessions
When working with sessions, there are a few things to consider before designing or redesigning a Web application:
There's another architecture that deals with maintaining state for a client. Instead of relying on the HttpSession interface, state for clients can be maintained within Enterprise JavaBeans (EJBs). The EJB architecture takes the business logic for an application and places it in components or beans. A session bean is a type of EJB that exists for a given client/server session and provides database access or other business logic, such as calculations. Session beans can be stateless or they can maintain the state for a client, very much like an HttpSession object.
There is still some debate over where the state for a Web site visitor should be maintained. The best design for the application at this time is to continue using the HttpSession object for maintaining the state of the presentation layer of the Web application and to use stateful EJBs to maintain the state of the business logic and data layer. There are many other factors that should be considered with EJBs, one being the better performance of stateless beans over those that maintain state. These issues, which are outside the scope of this article, should be considered carefully when architecting an application.
Session Timeout
By default, on most servers
the session is set to expire after 30 minutes of inactivity. The amount
of time can be configured in the deployment descriptor of the Web
application. The HttpSession API also provides a
setMaxInactiveInterval() method that you can use to specify the timeout
period for a session. The getMaxInactiveInterval() method will return
this timeout value. The value given is in seconds.
The length of time will vary depending on what your visitors are doing on your site. If they're logging in to check their account balance, a shorter session timeout period can be used because it doesn't take long for a person to read a couple of numbers. If, on the other hand, the user is logging in to read large amounts of data, you need to be sure that you provide enough time for the user to do what he or she wants without being logged out. If the user is constantly navigating through your site, the session will last indefinitely.
Implement Serializable
It's important to
make sure that all objects placed in the session can be serialized.
This may not be an issue if you know that your Web application will not
run in a cluster, but it should still be done anyway. What happens if
your Web site grows too big for one server and you suddenly have to
move to two? If you implement Serializable in your code now, you won't
have to go back and do it later.
Keep It Simple
You should design objects
that are going to be placed into a session so that they're not too big
and don't contain unnecessary information. A JavaBean that contains a
customer's name, address, phone number, e-mail address, credit card
numbers, and order history should not be placed into the session if
you're only going to use the object to get the customer's name.
Session Contents
When you're working on a
Web site, it's important to know which objects are in the session and
why they're needed. The size of the session should be kept as small as
possible. If you're building a new Web site, work out ahead of time
what goes in the session, why it's there, and where it gets removed. If
you're redesigning an existing site, this may be a little tougher,
especially when you have hundreds of servlets and JSPs to deal with. In
this case, try implementing an HttpSessionAttributeListener to get an
idea of what is going into the session. With this information, you may
be able to better manage your sessions.
Conclusion
Hopefully this article helped
you to better understand the design issues involved in using the
HttpSession interface. Java provides a more robust session
implementation than other languages. It's because of this power and
flexibility that you must take the time to properly lay out the use of
the session. A well-designed session will help make a Web application
better for the programmers and the users.
References
O'Reilly的Java|站. 每周都有新文?/span>
官方的Java开发者网?- 每周都有新文章发?/p>
由Gamelan.com l护的Java技术文章网?/span>
Sun公司l护的一个JavaC|站
http://www.ibm.com/developerworks/java
IBM的Developerworks技术网? q是其中的Java技术主?/p>
最早的一个Java站点. 每周更新Java技术文?/span>
http://www.javadesktop.org位于Java.net的一个Java桌面技术社区网?
q是一个讨论所有Java服务器端技术的|站.
提供Java评论服务. 包括各种framework和应用程?/p>
http://www.ibiblio.org/javafaq/javafaq.html
comp.lang.java的FAQ站点 - 攉了来自comp.lang.java新闻l的问题和答案的分类目录.
http://java.sun.com/docs/books/tutorial/
来自SUN公司的官方Java指南 - 对于了解几乎所有的java技术特性非常有帮助.
互联|上最z跃的一个Java Blog|站. Java Codes
l果为:
true
true
首先Q我们要知结果ؓ?/span>
Java
会确保一个字W串帔R只有一个拷?/span>
?/span>
因ؓ例子中的
s0
?/span>
s1
中的
”kvill?/span>
都是字符串常量,它们在编译期p定?/span>Q所?/span>
s0==s1
?/span>
true
Q?/span>
”kv?/span>
?/span>
”ill?/span>
也都是字W串帔RQ当一个字W串由多个字W串帔Rq接而成Ӟ它自p定也是字W串帔RQ所?/span>
s2
也同样在~译期就被解析ؓ一个字W串帔RQ所?/span>
s2
也是帔R池中
”kvill?/span>
的一个引用?/span>
所以我们得?/span>
s0==s1==s2;
?/span>
new String()
创徏的字W串不是帔RQ不能在~译期就定Q所?/span>
new String()
创徏的字W串不放入常量池中,它们有自q地址I间?/span>
看例
2
Q?/span>
String s0=”kvill?
String s1=new String(”kvill?;
String s2=”kv?+ new String(“ill?;
System.out.println( s0==s1 );
System.out.println( s0==s2 );
System.out.println( s1==s2 );
l果为:
false
false
false
?/span>
2
?/span>
s0
q是帔R池中
”kvill?/span>
的应用,
s1
因ؓ无法在编译期定Q所以是q行时创建的新对?/span>
”kvill?/span>
的引用,
s2
因ؓ有后半部?/span>
new String(“ill?
所以也无法在编译期定Q所以也是一个新创徏对象
”kvill?/span>
的应?/span>
;
明白了这些也q道ؓ何得出此l果了?/span>
4. String.intern()
Q?/span>
再补充介l一点:存在?/span>
.class
文g中的帔R池,在运行期?/span>
JVM
装蝲Qƈ且可以扩充?/span>
String
?/span>
intern()
Ҏ是扩充帔R池的一个方法;当一?/span>
String
实例
str
调用
intern()
ҎӞ
Java
查找帔R池中是否有相?/span>
Unicode
的字W串帔RQ如果有Q则q回其的引用Q如果没有,则在帔R池中增加一?/span>
Unicode
{于
str
的字W串q返回它的引用;看例
3
清楚了
?/span>
3
Q?/span>
String s0= “kvill?
String s1=new String(”kvill?;
String s2=new String(“kvill?;
System.out.println( s0==s1 );
System.out.println( ?*********?);
s1.intern();
s2=s2.intern(); //
把常量池?/span>
“kvill?/span>
的引用赋l?/span>
s2
System.out.println( s0==s1);
System.out.println( s0==s1.intern() );
System.out.println( s0==s2 );
l果为:
false
**********
false //
虽然执行?/span>
s1.intern(),
但它的返回值没有赋l?/span>
s1
true //
说明
s1.intern()
q回的是帔R池中
”kvill?/span>
的引?/span>
true
最后我再破除一个错误的理解Q有Q?/span>
?/span>
使用
String.intern()
Ҏ则可以将一?/span>
String
cȝ保存C个全局
String
表中Q如果具有相同值的
Unicode
字符串已l在q个表中Q那么该Ҏq回表中已有字符串的地址Q如果在表中没有相同值的字符Ԍ则将自己的地址注册到表?/span>
?/span>
如果我把他说的这个全局?/span>
String
表理解ؓ帔R池的话,他的最后一句话Q?/span>
?/span>
如果在表中没有相同值的字符Ԍ则将自己的地址注册到表?/span>
?/span>
是错的:
看例
4
Q?/span>
String s1=new String("kvill");
String s2=s1.intern();
System.out.println( s1==s1.intern() );
System.out.println( s1+" "+s2 );
System.out.println( s2==s1.intern() );
l果Q?/span>
false
kvill kvill
true
在这个类中我们没有声名一?/span>
”kvill?/span>
帔RQ所以常量池中一开始是没有
”kvill?/span>
的,当我们调?/span>
s1.intern()
后就在常量池中新d了一?/span>
”kvill?/span>
帔RQ原来的不在帔R池中?/span>
”kvill?/span>
仍然存在Q也׃?/span>
?/span>
自q地址注册到常量池?/span>
?/span>
了?/span>
s1==s1.intern()
?/span>
false
说明原来?/span>
“kvill?/span>
仍然存在Q?/span>
s2
现在为常量池?/span>
“kvill?/span>
的地址Q所以有
s2==s1.intern()
?/span>
true
?/span>
5.
关于
equals()
?/span>
==
q个对于
String
单来说就是比较两字符串的
Unicode
序列是否相当Q如果相{返?/span>
true;
?/span>
==
是比较两字符串的地址是否相同Q也是是否是同一个字W串的引用?/span>
6.
关于
String
是不可变?/span>
q一说又要说很多Q大家只要知?/span>
String
的实例一旦生成就不会再改变了Q比如说Q?/span>
String str=”kv?”ill???”ans?
是?/span>
4
个字W串帔RQ首?/span>
”kv?/span>
?/span>
”ill?/span>
生成?/span>
”kvill?/span>
存在内存中,然后
”kvill?/span>
又和
??
生成
”kvill ?/span>
存在内存中,最后又和生成了
”kvill ans?
q把q个字符串的地址赋给?/span>
str,
是因ؓ
String
?/span>
?/span>
不可?/span>
?/span>
产生了很多时变量,q也是Z么徏议用
StringBuffer
的原因了Q因?/span>
StringBuffer
是可改变的?/span>
2
、抽象类Q抽象类中可以不包含抽象ҎQ即cM的方法都是非抽象的,但是在类的声明中加上
abstract
Q以使得该类是抽象的Q目的是防止客户端程序员创徏该类的对象;
3
、接口中的方法L
abstract and public
Q不是否被昄的声明;
4
、接口中?/span>
field
只能?/span>
public static final
Q?/span>
5
、接口本w可以是
public or protected
Q?/span>
6
?/span>
extended class
必须实现抽象cM的所有抽象方法,
implemented class
必须实现接口中的所有方法,因ؓ接口中的所有方法都?/span>
abstract
?/span>
Section One: Configuring Web Applications
Mapping URLs to Web Components
When a request is received by the web container it must determine which web component should handle the request. It does so by mapping the URL path contained in the request to a web application and a web component. A URL path contains the context root and an alias:
http://host
:port
/context_root
/alias
A context root identifies a web application in a Java EE server. You specify the context root when you deploy a web module. A context root must start with a forward slash (/) and end with a string.
The alias identifies the web component that should handle a request. The alias path must start with a forward slash (/) and end with a string or a wildcard expression with an extension (for example, *.jsp). Since web containers automatically map an alias that ends with *.jsp, you do not have to specify an alias for a JSP page unless you wish to refer to the page by a name other than its file name.
Declaring Welcome Files
For example, suppose you define a welcome file welcome.html. When a client requests a URL such as host:port/webapp/directory, where directory is not mapped to a servlet or JSP page, the file host:port/webapp/directory/welcome.html is returned to the client.
If no welcome file is specified, the Application Server will use a file named index.
XXX
, where XXX
can be html
or jsp
, as the default welcome file. If there is no welcome file and no file named index.
XXX
, the Application Server returns a directory listing.
To specify a welcome file in the web application deployment descriptor, you need to nest a welcome-file
element inside a welcome-file-list
element. The welcome-file
element defines the JSP page to be used as the welcome page. Make sure this JSP page is actually included in your WAR file.
Setting Initialization Parameters
The web components in a web module share an object that represents their application context. You can pass initialization parameters to the context or to a web component.
To add a context parameter you need the following in the example's web.xml file:
To add a web component initialization parameter you need the following in the example's web.xml file:
Mapping Errors to Error Screens
Declaring Resource References