锘??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鐨凧ava緗戠珯. 姣忓懆閮芥湁鏂版枃绔?/span>
瀹樻柟鐨凧ava寮鍙戣呯綉绔?- 姣忓懆閮芥湁鏂版枃绔犲彂琛?/p>
鐢盙amelan.com 緇存姢鐨凧ava鎶鏈枃绔犵綉绔?/span>
Sun鍏徃緇存姢鐨勪竴涓狫ava紺懼尯緗戠珯
http://www.ibm.com/developerworks/java
IBM鐨凞eveloperworks鎶鏈綉绔? 榪欐槸鍏朵腑鐨凧ava鎶鏈富欏?/p>
鏈鏃╃殑涓涓狫ava绔欑偣. 姣忓懆鏇存柊Java鎶鏈枃绔?/span>
http://www.javadesktop.org浣嶄簬Java.net鐨勪竴涓狫ava妗岄潰鎶鏈ぞ鍖虹綉绔?
榪欐槸涓涓璁烘墍鏈塉ava鏈嶅姟鍣ㄧ鎶鏈殑緗戠珯.
鎻愪緵Java璇勮鏈嶅姟. 鍖呮嫭鍚勭framework鍜屽簲鐢ㄧ▼搴?/p>
http://www.ibiblio.org/javafaq/javafaq.html
comp.lang.java鐨凢AQ绔欑偣 - 鏀墮泦浜嗘潵鑷猚omp.lang.java鏂伴椈緇勭殑闂鍜岀瓟妗堢殑鍒嗙被鐩綍.
http://java.sun.com/docs/books/tutorial/
鏉ヨ嚜SUN鍏徃鐨勫畼鏂笿ava鎸囧崡 - 瀵逛簬浜嗚В鍑犱箮鎵鏈夌殑java鎶鏈壒鎬ч潪甯告湁甯姪.
浜掕仈緗戜笂鏈媧昏穬鐨勪竴涓狫ava Blog緗戠珯. Java Codes
銆銆緇撴灉涓猴細
true
true
銆銆棣栧厛錛屾垜浠鐭ョ粨鏋滀負閬?/span>
Java
浼氱‘淇濅竴涓瓧絎︿覆甯擱噺鍙湁涓涓嫹璐?/span>
銆?/span>
銆銆鍥犱負渚嬪瓙涓殑
s0
鍜?/span>
s1
涓殑
鈥漦vill鈥?/span>
閮芥槸瀛楃涓插父閲忥紝瀹冧滑鍦ㄧ紪璇戞湡灝辮紜畾浜?/span>錛屾墍浠?/span>
s0==s1
涓?/span>
true
錛涜?/span>
鈥漦v鈥?/span>
鍜?/span>
鈥漣ll鈥?/span>
涔熼兘鏄瓧絎︿覆甯擱噺錛屽綋涓涓瓧絎︿覆鐢卞涓瓧絎︿覆甯擱噺榪炴帴鑰屾垚鏃訛紝瀹冭嚜宸辮偗瀹氫篃鏄瓧絎︿覆甯擱噺錛屾墍浠?/span>
s2
涔熷悓鏍峰湪緙栬瘧鏈熷氨琚В鏋愪負涓涓瓧絎︿覆甯擱噺錛屾墍浠?/span>
s2
涔熸槸甯擱噺姹犱腑
鈥漦vill鈥?/span>
鐨勪竴涓紩鐢ㄣ?/span>
銆銆鎵浠ユ垜浠緱鍑?/span>
s0==s1==s2;
鐢?/span>
new String()
鍒涘緩鐨勫瓧絎︿覆涓嶆槸甯擱噺錛屼笉鑳藉湪緙栬瘧鏈熷氨紜畾錛屾墍浠?/span>
new String()
鍒涘緩鐨勫瓧絎︿覆涓嶆斁鍏ュ父閲忔睜涓紝瀹冧滑鏈夎嚜宸辯殑鍦板潃絀洪棿銆?/span>
銆銆鐪嬩緥
2
錛?/span>
String s0=鈥漦vill鈥?
String s1=new String(鈥漦vill鈥?;
String s2=鈥漦v鈥?+ new String(鈥渋ll鈥?;
System.out.println( s0==s1 );
System.out.println( s0==s2 );
System.out.println( s1==s2 );
銆銆緇撴灉涓猴細
false
false
false
銆銆渚?/span>
2
涓?/span>
s0
榪樻槸甯擱噺姹犱腑
鈥漦vill鈥?/span>
鐨勫簲鐢紝
s1
鍥犱負鏃犳硶鍦ㄧ紪璇戞湡紜畾錛屾墍浠ユ槸榪愯鏃跺垱寤虹殑鏂板璞?/span>
鈥漦vill鈥?/span>
鐨勫紩鐢紝
s2
鍥犱負鏈夊悗鍗婇儴鍒?/span>
new String(鈥渋ll鈥?
鎵浠ヤ篃鏃犳硶鍦ㄧ紪璇戞湡紜畾錛屾墍浠ヤ篃鏄竴涓柊鍒涘緩瀵硅薄
鈥漦vill鈥?/span>
鐨勫簲鐢?/span>
;
鏄庣櫧浜嗚繖浜涗篃灝辯煡閬撲負浣曞緱鍑烘緇撴灉浜嗐?/span>
4. String.intern()
錛?/span>
銆銆鍐嶈ˉ鍏呬粙緇嶄竴鐐癸細瀛樺湪浜?/span>
.class
鏂囦歡涓殑甯擱噺姹狅紝鍦ㄨ繍琛屾湡琚?/span>
JVM
瑁呰澆錛屽茍涓斿彲浠ユ墿鍏呫?/span>
String
鐨?/span>
intern()
鏂規硶灝辨槸鎵╁厖甯擱噺姹犵殑涓涓柟娉曪紱褰撲竴涓?/span>
String
瀹炰緥
str
璋冪敤
intern()
鏂規硶鏃訛紝
Java
鏌ユ壘甯擱噺姹犱腑鏄惁鏈夌浉鍚?/span>
Unicode
鐨勫瓧絎︿覆甯擱噺錛屽鏋滄湁錛屽垯榪斿洖鍏剁殑寮曠敤錛屽鏋滄病鏈夛紝鍒欏湪甯擱噺姹犱腑澧炲姞涓涓?/span>
Unicode
絳変簬
str
鐨勫瓧絎︿覆騫惰繑鍥炲畠鐨勫紩鐢紱鐪嬩緥
3
灝辨竻妤氫簡
銆銆渚?/span>
3
錛?/span>
String s0= 鈥渒vill鈥?
String s1=new String(鈥漦vill鈥?;
String s2=new String(鈥渒vill鈥?;
System.out.println( s0==s1 );
System.out.println( 鈥?*********鈥?);
s1.intern();
s2=s2.intern(); //
鎶婂父閲忔睜涓?/span>
鈥渒vill鈥?/span>
鐨勫紩鐢ㄨ祴緇?/span>
s2
System.out.println( s0==s1);
System.out.println( s0==s1.intern() );
System.out.println( s0==s2 );
銆銆緇撴灉涓猴細
false
**********
false //
铏界劧鎵ц浜?/span>
s1.intern(),
浣嗗畠鐨勮繑鍥炲兼病鏈夎祴緇?/span>
s1
true //
璇存槑
s1.intern()
榪斿洖鐨勬槸甯擱噺姹犱腑
鈥漦vill鈥?/span>
鐨勫紩鐢?/span>
true
銆銆鏈鍚庢垜鍐嶇牬闄や竴涓敊璇殑鐞嗚В錛氭湁浜鴻錛?/span>
鈥?/span>
浣跨敤
String.intern()
鏂規硶鍒欏彲浠ュ皢涓涓?/span>
String
綾葷殑淇濆瓨鍒頒竴涓叏灞
String
琛ㄤ腑錛屽鏋滃叿鏈夌浉鍚屽肩殑
Unicode
瀛楃涓插凡緇忓湪榪欎釜琛ㄤ腑錛岄偅涔堣鏂規硶榪斿洖琛ㄤ腑宸叉湁瀛楃涓茬殑鍦板潃錛屽鏋滃湪琛ㄤ腑娌℃湁鐩稿悓鍊肩殑瀛楃涓詫紝鍒欏皢鑷繁鐨勫湴鍧娉ㄥ唽鍒拌〃涓?/span>
鈥?/span>
濡傛灉鎴戞妸浠栬鐨勮繖涓叏灞鐨?/span>
String
琛ㄧ悊瑙d負甯擱噺姹犵殑璇濓紝浠栫殑鏈鍚庝竴鍙ヨ瘽錛?/span>
鈥?/span>
濡傛灉鍦ㄨ〃涓病鏈夌浉鍚屽肩殑瀛楃涓詫紝鍒欏皢鑷繁鐨勫湴鍧娉ㄥ唽鍒拌〃涓?/span>
鈥?/span>
鏄敊鐨勶細
銆銆鐪嬩緥
4
錛?/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() );
銆銆緇撴灉錛?/span>
false
kvill kvill
true
銆銆鍦ㄨ繖涓被涓垜浠病鏈夊0鍚嶄竴涓?/span>
鈥漦vill鈥?/span>
甯擱噺錛屾墍浠ュ父閲忔睜涓竴寮濮嬫槸娌℃湁
鈥漦vill鈥?/span>
鐨勶紝褰撴垜浠皟鐢?/span>
s1.intern()
鍚庡氨鍦ㄥ父閲忔睜涓柊娣誨姞浜嗕竴涓?/span>
鈥漦vill鈥?/span>
甯擱噺錛屽師鏉ョ殑涓嶅湪甯擱噺姹犱腑鐨?/span>
鈥漦vill鈥?/span>
浠嶇劧瀛樺湪錛屼篃灝變笉鏄?/span>
鈥?/span>
灝嗚嚜宸辯殑鍦板潃娉ㄥ唽鍒板父閲忔睜涓?/span>
鈥?/span>
浜嗐?/span>
銆銆
s1==s1.intern()
涓?/span>
false
璇存槑鍘熸潵鐨?/span>
鈥渒vill鈥?/span>
浠嶇劧瀛樺湪錛?/span>
s2
鐜板湪涓哄父閲忔睜涓?/span>
鈥渒vill鈥?/span>
鐨勫湴鍧錛屾墍浠ユ湁
s2==s1.intern()
涓?/span>
true
銆?/span>
5.
鍏充簬
equals()
鍜?/span>
==
銆銆榪欎釜瀵逛簬
String
綆鍗曟潵璇村氨鏄瘮杈冧袱瀛楃涓茬殑
Unicode
搴忓垪鏄惁鐩稿綋錛屽鏋滅浉絳夎繑鍥?/span>
true;
鑰?/span>
==
鏄瘮杈冧袱瀛楃涓茬殑鍦板潃鏄惁鐩稿悓錛屼篃灝辨槸鏄惁鏄悓涓涓瓧絎︿覆鐨勫紩鐢ㄣ?/span>
6.
鍏充簬
String
鏄笉鍙彉鐨?/span>
銆銆榪欎竴璇村張瑕佽寰堝錛屽ぇ瀹跺彧瑕佺煡閬?/span>
String
鐨勫疄渚嬩竴鏃︾敓鎴愬氨涓嶄細鍐嶆敼鍙樹簡錛屾瘮濡傝錛?/span>
String str=鈥漦v鈥?鈥漣ll鈥?鈥?鈥?鈥漚ns鈥?
銆銆灝辨槸鏈?/span>
4
涓瓧絎︿覆甯擱噺錛岄鍏?/span>
鈥漦v鈥?/span>
鍜?/span>
鈥漣ll鈥?/span>
鐢熸垚浜?/span>
鈥漦vill鈥?/span>
瀛樺湪鍐呭瓨涓紝鐒跺悗
鈥漦vill鈥?/span>
鍙堝拰
鈥?鈥?
鐢熸垚
鈥漦vill 鈥?/span>
瀛樺湪鍐呭瓨涓紝鏈鍚庡張鍜岀敓鎴愪簡
鈥漦vill ans鈥?
騫舵妸榪欎釜瀛楃涓茬殑鍦板潃璧嬬粰浜?/span>
str,
灝辨槸鍥犱負
String
鐨?/span>
鈥?/span>
涓嶅彲鍙?/span>
鈥?/span>
浜х敓浜嗗緢澶氫復鏃跺彉閲忥紝榪欎篃灝辨槸涓轟粈涔堝緩璁敤
StringBuffer
鐨勫師鍥犱簡錛屽洜涓?/span>
StringBuffer
鏄彲鏀瑰彉鐨勩?/span>
2
銆佹娊璞$被錛氭娊璞$被涓彲浠ヤ笉鍖呭惈鎶借薄鏂規硶錛屽嵆綾諱腑鐨勬柟娉曢兘鏄潪鎶借薄鐨勶紝浣嗘槸鍦ㄧ被鐨勫0鏄庝腑鍔犱笂
abstract
錛屼互浣垮緱璇ョ被鏄娊璞$殑錛岀洰鐨勬槸闃叉瀹㈡埛绔▼搴忓憳鍒涘緩璇ョ被鐨勫璞★紱
3
銆佹帴鍙d腑鐨勬柟娉曟繪槸
abstract and public
錛屼笉綆℃槸鍚﹁鏄劇ず鐨勫0鏄庯紱
4
銆佹帴鍙d腑鐨?/span>
field
鍙兘鏄?/span>
public static final
錛?/span>
5
銆佹帴鍙f湰韜彲浠ユ槸
public or protected
錛?/span>
6
銆?/span>
extended class
蹇呴』瀹炵幇鎶借薄綾諱腑鐨勬墍鏈夋娊璞℃柟娉曪紝
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