TOCMAT的web.xml詳解
1 定義頭和根元素
部署描述符文件就像所有XML文件一樣，必須以一個XML頭開始。這個頭聲明可以使用的XML版本並給出文件的字符編碼。
DOCYTPE聲明必須立即出現在此頭之後。這個聲明告訴服務器適用的servlet規範的版本（如2.2或2.3）並指定管理此文件其餘部分內容的語法的DTD(Document Type Definition，文檔類型定義)。
所有部署描述符文件的頂層（根）元素爲web-app。請注意，XML元素不像HTML，他們是大小寫敏感的。因此，web-App和WEB-APP都是不合法的，web-app必須用小寫。
2 部署描述符文件內的元素次序
XML元素不僅是大小寫敏感的，而且它們還對出現在其他元素中的次序敏感。例如，XML頭必須是文件中的第一項，DOCTYPE聲明必須是第二項，而web-app元素必須是第三項。在web-app元素內，元素的次序也很重要。服務器不一定強制要求這種次序，但它們允許（實際上有些服務器就是這樣做的）完全拒絕執行含有次序不正確的元素的Web應用。這表示使用非標準元素次序的web.xml文件是不可移植的。
下面的列表給出了所有可直接出現在web-app元素內的合法元素所必需的次序。例如，此列表說明servlet元素必須出現在所有servlet-mapping元素之前。請注意，所有這些元素都是可選的。因此，可以省略掉某一元素，但不能把它放於不正確的位置。
l icon icon元素指出IDE和GUI工具用來表示Web應用的一個和兩個圖像文件的位置。
l display-name display-name元素提供GUI工具可能會用來標記這個特定的Web應用的一個名稱。
l description description元素給出與此有關的說明性文本。
l context-param context-param元素聲明應用範圍內的初始化參數。
l filter 過濾器元素將一個名字與一個實現javax.servlet.Filter接口的類相關聯。
l filter-mapping 一旦命名了一個過濾器，就要利用filter-mapping元素把它與一個或多個servlet或JSP頁面相關聯。
llistener servlet API的版本2.3增加了對事件監聽程序的支持，事件監聽程序在建立、修改和刪除會話或servlet環境時得到通知。Listener元素指出事件監聽程序類。
lservlet 在向servlet或JSP頁面制定初始化參數或定製URL時，必須首先命名servlet或JSP頁面。Servlet元素就是用來完成此項任務的。
lservlet-mapping 服務器一般爲servlet提供一個缺省的URL：http://host/webAppPrefix/servlet/ServletName。但是，常常會更改這個URL，以便servlet可以訪問初始化參數或更容易地處理相對URL。在更改缺省URL時，使用servlet-mapping元素。
lsession-config 如果某個會話在一定時間內未被訪問，服務器可以拋棄它以節省內存。可通過使用HttpSession的setMaxInactiveInterval方法明確設置單個會話對象的超時值，或者可利用session-config元素制定缺省超時值。
lmime-mapping 如果Web應用具有想到特殊的文件，希望能保證給他們分配特定的MIME類型，則mime-mapping元素提供這種保證。
lwelcom-file-list welcome-file-list元素指示服務器在收到引用一個目錄名而不是文件名的URL時，使用哪個文件。
l error-page error-page元素使得在返回特定HTTP狀態代碼時，或者特定類型的異常被拋出時，能夠制定將要顯示的頁面。
l taglib taglib元素對標記庫描述符文件（Tag Libraryu Descriptor file）指定別名。此功能使你能夠更改TLD文件的位置，而不用編輯使用這些文件的JSP頁面。
l resource-env-ref resource-env-ref元素聲明與資源相關的一個管理對象。
l resource-ref resource-ref元素聲明一個資源工廠使用的外部資源。
l security-constraint security-constraint元素制定應該保護的URL。它與login-config元素聯合使用
l login-config 用login-config元素來指定服務器應該怎樣給試圖訪問受保護頁面的用戶授權。它與sercurity-constraint元素聯合使用。
l security-role security-role元素給出安全角色的一個列表，這些角色將出現在servlet元素內的security-role-ref元素的role-name子元素中。分別地聲明角色可使高級IDE處理安全信息更爲容易。
l env-entry env-entry元素聲明Web應用的環境項。
l ejb-ref ejb-ref元素聲明一個EJB的主目錄的引用。
l ejb-local-ref ejb-local-ref元素聲明一個EJB的本地主目錄的應用。
3 分配名稱和定製的UL
在web.xml中完成的一個最常見的任務是對servlet或JSP頁面給出名稱和定製的URL。用servlet元素分配名稱，使用servlet-mapping元素將定製的URL與剛分配的名稱相關聯。
3.1 分配名稱
爲了提供初始化參數，對servlet或JSP頁面定義一個定製URL或分配一個安全角色，必須首先給servlet或JSP頁面一個名稱。可通過servlet元素分配一個名稱。最常見的格式包括servlet-name和servlet-class子元素（在web-app元素內），如下所示：
<servlet>
<servlet-name>Test</servlet-name>
<servlet-class>moreservlets.TestServlet</servlet-class>
</servlet>
這表示位於WEB-INF/classes/moreservlets/TestServlet的servlet已經得到了註冊名Test。給servlet一個名稱具有兩個主要的含義。首先，初始化參數、定製的URL模式以及其他定製通過此註冊名而不是類名引用此servlet。其次,可在URL而不是類名中使用此名稱。因此，利用剛纔給出的定義，URL http://host/webAppPrefix/servlet/Test 可用於 http://host/webAppPrefix/servlet/moreservlets.TestServlet 的場所。
請記住：XML元素不僅是大小寫敏感的，而且定義它們的次序也很重要。例如，web-app元素內所有servlet元素必須位於所有servlet-mapping元素（下一小節介紹）之前，而且還要位於5.6節和5.11節討論的與過濾器或文檔相關的元素（如果有的話）之前。類似地，servlet的servlet-name子元素也必須出現在servlet-class之前。5.2節"部署描述符文件內的元素次序"將詳細介紹這種必需的次序。
例如，程序清單5-1給出了一個名爲TestServlet的簡單servlet，它駐留在moreservlets程序包中。因爲此servlet是紮根在一個名爲deployDemo的目錄中的Web應用的組成部分，所以TestServlet.class放在deployDemo/WEB-INF/classes/moreservlets中。程序清單5-2給出將放置在deployDemo/WEB-INF/內的web.xml文件的一部分。此web.xml文件使用servlet-name和servlet-class元素將名稱Test與TestServlet.class相關聯。圖5-1和圖5-2分別顯示利用缺省URL和註冊名調用TestServlet時的結果。
程序清單5-1 TestServlet.java
package moreservlets;
import JAVA.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
/** Simple servlet used to illustrate servlet naming
* and custom URLs.
* <P>
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class TestServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String uri = request.getRequestURI();
out.println(ServletUtilities.headWithTitle("Test Servlet") +
"<BODY BGCOLOR=/"#FDF5E6/">/n" +
"<H2>URI: " + uri + "</H2>/n" +
"</BODY></HTML>");
}
}
程序清單5-2 web.xml（說明servlet名稱的摘錄）
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- … -->
<servlet>
<servlet-name>Test</servlet-name>
<servlet-class>moreservlets.TestServlet</servlet-class>
</servlet>
<!-- … -->
</web-app>
3.2 定義定製的URL
大多數服務器具有一個缺省的serlvet URL：
http://host/webAppPrefix/servlet/packageName.ServletName。雖然在開發中使用這個URL很方便，但是我們常常會希望另一個URL用於部署。例如，可能會需要一個出現在Web應用頂層的URL（如，http://host/webAppPrefix/Anyname），並且在此URL中沒有servlet項。位於頂層的URL簡化了相對URL的使用。此外，對許多開發人員來說，頂層URL看上去比更長更麻煩的缺省URL更簡短。
事實上，有時需要使用定製的URL。比如，你可能想關閉缺省URL映射，以便更好地強制實施安全限制或防止用戶意外地訪問無初始化參數的servlet。如果你禁止了缺省的URL，那麼你怎樣訪問servlet呢？這時只有使用定製的URL了。
爲了分配一個定製的URL，可使用servlet-mapping元素及其servlet-name和url-pattern子元素。Servlet-name元素提供了一個任意名稱，可利用此名稱引用相應的servlet；url-pattern描述了相對於Web應用的根目錄的URL。url-pattern元素的值必須以斜槓（/）起始。
下面給出一個簡單的web.xml摘錄，它允許使用URL http://host/webAppPrefix/UrlTest而不是http://host/webAppPrefix/servlet/Test或
http://host/webAppPrefix/servlet/moreservlets.TestServlet。請注意，仍然需要XML頭、DOCTYPE聲明以及web-app封閉元素。此外，可回憶一下，XML元素出現地次序不是隨意的。特別是，需要把所有servlet元素放在所有servlet-mapping元素之前。
<servlet>
<servlet-name>Test</servlet-name>
<servlet-class>moreservlets.TestServlet</servlet-class>
</servlet>
<!-- ... -->
<servlet-mapping>
<servlet-name>Test</servlet-name>
<url-pattern>/UrlTest</url-pattern>
</servlet-mapping>
URL模式還可以包含通配符。例如，下面的小程序指示服務器發送所有以Web應用的URL前綴開始，以..asp結束的請求到名爲BashMS的servlet。
<servlet>
<servlet-name>BashMS</servlet-name>
<servlet-class>msUtils.ASPTranslator</servlet-class>
</servlet>
<!-- ... -->
<servlet-mapping>
<servlet-name>BashMS</servlet-name>
<url-pattern>/*.asp</url-pattern>
</servlet-mapping>
3.3 命名JSP頁面
因爲JSP頁面要轉換成sevlet，自然希望就像命名servlet一樣命名JSP頁面。畢竟，JSP頁面可能會從初始化參數、安全設置或定製的URL中受益，正如普通的serlvet那樣。雖然JSP頁面的後臺實際上是servlet這句話是正確的，但存在一個關鍵的猜疑：即，你不知道JSP頁面的實際類名（因爲系統自己挑選這個名字）。因此，爲了命名JSP頁面，可將jsp-file元素替換爲servlet-calss元素，如下所示：
<servlet>
<servlet-name>Test</servlet-name>
<jsp-file>/TestPage.jsp</jsp-file>
</servlet>
命名JSP頁面的原因與命名servlet的原因完全相同：即爲了提供一個與定製設置（如，初始化參數和安全設置）一起使用的名稱，並且，以便能更改激活JSP頁面的URL（比方說，以便多個URL通過相同頁面得以處理，或者從URL中去掉.jsp擴展名）。但是，在設置初始化參數時，應該注意，JSP頁面是利用jspInit方法，而不是init方法讀取初始化參數的。
例如，程序清單5-3給出一個名爲TestPage.jsp的簡單JSP頁面，它的工作只是打印出用來激活它的URL的本地部分。TestPage.jsp放置在deployDemo應用的頂層。程序清單5-4給出了用來分配一個註冊名PageName，然後將此註冊名與http://host/webAppPrefix/UrlTest2/anything 形式的URL相關聯的web.xml文件（即，deployDemo/WEB-INF/web.xml）的一部分。
程序清單5-3 TestPage.jsp
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE>
JSP Test Page
</TITLE>
</HEAD>
<BODY BGCOLOR="#FDF5E6">
<H2>URI: <%= request.getRequestURI() %></H2>
</BODY>
</HTML>
程序清單5-4 web.xml（說明JSP頁命名的摘錄）
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- ... -->
<servlet>
<servlet-name>PageName</servlet-name>
<jsp-file>/TestPage.jsp</jsp-file>
</servlet>
<!-- ... -->
<servlet-mapping>
<servlet-name> PageName </servlet-name>
<url-pattern>/UrlTest2/*</url-pattern>
</servlet-mapping>
<!-- ... -->
</web-app>
4 禁止激活器servlet
對servlet或JSP頁面建立定製URL的一個原因是，這樣做可以註冊從init（servlet）或jspInit（JSP頁面）方法中讀取得初始化參數。但是，初始化參數只在是利用定製URL模式或註冊名訪問servlet或JSP頁面時可以使用，用缺省URL http://host/webAppPrefix/servlet/ServletName 訪問時不能使用。因此，你可能會希望關閉缺省URL，這樣就不會有人意外地調用初始化servlet了。這個過程有時稱爲禁止激活器servlet，因爲多數服務器具有一個用缺省的servlet URL註冊的標準servlet，並激活缺省的URL應用的實際servlet。
有兩種禁止此缺省URL的主要方法：
l 在每個Web應用中重新映射/servlet/模式。
l 全局關閉激活器servlet。
重要的是應該注意到，雖然重新映射每個Web應用中的/servlet/模式比徹底禁止激活servlet所做的工作更多，但重新映射可以用一種完全可移植的方式來完成。相反，全局禁止激活器servlet完全是針對具體機器的，事實上有的服務器（如ServletExec）沒有這樣的選擇。下面的討論對每個Web應用重新映射/servlet/ URL模式的策略。後面提供在Tomcat中全局禁止激活器servlet的詳細內容。
4.1 重新映射/servlet/URL模式
在一個特定的Web應用中禁止以http://host/webAppPrefix/servlet/ 開始的URL的處理非常簡單。所需做的事情就是建立一個錯誤消息servlet，並使用前一節討論的url-pattern元素將所有匹配請求轉向該servlet。只要簡單地使用：
<url-pattern>/servlet/*</url-pattern>
作爲servlet-mapping元素中的模式即可。
例如，程序清單5-5給出了將SorryServlet servlet（程序清單5-6）與所有以http://host/webAppPrefix/servlet/ 開頭的URL相關聯的部署描述符文件的一部分。
程序清單5-5 web.xml（說明JSP頁命名的摘錄）
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- ... -->
<servlet>
<servlet-name>Sorry</servlet-name>
<servlet-class>moreservlets.SorryServlet</servlet-class>
</servlet>
<!-- ... -->
<servlet-mapping>
<servlet-name> Sorry </servlet-name>
<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>
<!-- ... -->
</web-app>
程序清單5-6 SorryServlet.java
package moreservlets;
import JAVA.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
/** Simple servlet used to give error messages to
* users who try to access default servlet URLs
* (i.e., http://host/webAppPrefix/servlet/ServletName)
* in Web applications that have disabled this
* behavior.
* <P>
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class SorryServlet extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String title = "Invoker Servlet Disabled.";
out.println(ServletUtilities.headWithTitle(title) +
"<BODY BGCOLOR=/"#FDF5E6/">/n" +
"<H2>" + title + "</H2>/n" +
"Sorry, access to servlets by means of/n" +
"URLs that begin with/n" +
"http://host/webAppPrefix/servlet//n" +
"has been disabled./n" +
"</BODY></HTML>");
}
public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
doGet(request, response);
}
}
4.2 全局禁止激活器：Tomcat
Tomcat 4中用來關閉缺省URL的方法與Tomcat 3中所用的很不相同。下面介紹這兩種方法：
1．禁止激活器： Tomcat 4
Tomcat 4用與前面相同的方法關閉激活器servlet，即利用web.xml中的url-mapping元素進行關閉。不同之處在於Tomcat使用了放在install_dir/conf中的一個服務器專用的全局web.xml文件，而前面使用的是存放在每個Web應用的WEB-INF目錄中的標準web.xml文件。
因此，爲了在Tomcat 4中關閉激活器servlet，只需在install_dir/conf/web.xml中簡單地註釋出/servlet/* URL映射項即可，如下所示：
<!--
<servlet-mapping>
<servlet-name>invoker</servlet-name>
<url-pattern>/servlet/*</url-pattern>
</servlet-mapping>
-->
再次提醒，應該注意這個項是位於存放在install_dir/conf的Tomcat專用的web.xml文件中的，此文件不是存放在每個Web應用的WEB-INF目錄中的標準web.xml。
2．禁止激活器：Tomcat3
在Apache Tomcat的版本3中，通過在install_dir/conf/server.xml中註釋出InvokerInterceptor項全局禁止缺省servlet URL。例如，下面是禁止使用缺省servlet URL的server.xml文件的一部分。
<!--
<RequsetInterceptor
className="org.apache.tomcat.request.InvokerInterceptor"
debug="0" prefix="/servlet/" />
-->
5 初始化和預裝載servlet與JSP頁面
這裏討論控制servlet和JSP頁面的啓動行爲的方法。特別是，說明了怎樣分配初始化參數以及怎樣更改服務器生存期中裝載servlet和JSP頁面的時刻。
5.1 分配servlet初始化參數
利用init-param元素向servlet提供初始化參數，init-param元素具有param-name和param-value子元素。例如，在下面的例子中，如果initServlet servlet是利用它的註冊名（InitTest）訪問的，它將能夠從其方法中調用getServletConfig().getInitParameter("param1")獲得"Value 1"，調用getServletConfig().getInitParameter("param2")獲得"2"。
<servlet>
<servlet-name>InitTest</servlet-name>
<servlet-class>moreservlets.InitServlet</servlet-class>
<init-param>
<param-name>param1</param-name>
<param-value>value1</param-value>
</init-param>
<init-param>
<param-name>param2</param-name>
<param-value>2</param-value>
</init-param>
</servlet>
在涉及初始化參數時，有幾點需要注意：
l 返回值。GetInitParameter的返回值總是一個String。因此，在前一個例子中，可對param2使用Integer.parseInt獲得一個int。
l JSP中的初始化。JSP頁面使用jspInit而不是init。JSP頁面還需要使用jsp-file元素代替servlet-class。
l 缺省URL。初始化參數只在通過它們的註冊名或與它們註冊名相關的定製URL模式訪問Servlet時可以使用。因此，在這個例子中，param1和param2初始化參數將能夠在使用URL http://host/webAppPrefix/servlet/InitTest 時可用，但在使用URL http://host/webAppPrefix/servlet/myPackage.InitServlet 時不能使用。
例如，程序清單5-7給出一個名爲InitServlet的簡單servlet，它使用init方法設置firstName和emailAddress字段。程序清單5-8給出分配名稱InitTest給servlet的web.xml文件。
程序清單5-7 InitServlet.java
package moreservlets;
import JAVA.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
/** Simple servlet used to illustrate servlet
* initialization parameters.
* <P>
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class InitServlet extends HttpServlet {
private String firstName, emailAddress;
public void init() {
ServletConfig config = getServletConfig();
firstName = config.getInitParameter("firstName");
emailAddress = config.getInitParameter("emailAddress");
}
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
String uri = request.getRequestURI();
out.println(ServletUtilities.headWithTitle("Init Servlet") +
"<BODY BGCOLOR=/"#FDF5E6/">/n" +
"<H2>Init Parameters:</H2>/n" +
"<UL>/n" +
"<LI>First name: " + firstName + "/n" +
"<LI>Email address: " + emailAddress + "/n" +
"</UL>/n" +
"</BODY></HTML>");
}
}
程序清單5-8 web.xml（說明初始化參數的摘錄）
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- ... -->
<servlet>
<servlet-name>InitTest</servlet-name>
<servlet-class>moreservlets.InitServlet</servlet-class>
<init-param>
<param-name>firstName</param-name>
<param-value>Larry</param-value>
</init-param>
<init-param>
<param-name>emailAddress</param-name>
<param-value>[email protected]</param-value>
</init-param>
</servlet>
<!-- ... -->
</web-app>
5.2 分配JSP初始化參數
給JSP頁面提供初始化參數在三個方面不同於給servlet提供初始化參數。
1）使用jsp-file而不是servlet-class。因此，WEB-INF/web.xml文件的servlet元素如下所示：
<servlet>
<servlet-name>PageName</servlet-name>
<jsp-file>/RealPage.jsp</jsp-file>
<init-param>
<param-name>...</param-name>
<param-value>...</param-value>
</init-param>
...
</servlet>
2)幾乎總是分配一個明確的URL模式。對servlet，一般相應地使用以http://host/webAppPrefix/servlet/ 開始的缺省URL。只需記住，使用註冊名而不是原名稱即可。這對於JSP頁面在技術上也是合法的。例如，在上面給出的例子中，可用URL http://host/webAppPrefix/servlet/PageName 訪問RealPage.jsp的對初始化參數具有訪問權的版本。但在用於JSP頁面時，許多用戶似乎不喜歡應用常規的servlet的URL。此外，如果JSP頁面位於服務器爲其提供了目錄清單的目錄中（如，一個既沒有index.html也沒有index.jsp文件的目錄），則用戶可能會連接到此JSP頁面，單擊它，從而意外地激活未初始化的頁面。因此，好的辦法是使用url-pattern（5.3節）將JSP頁面的原URL與註冊的servlet名相關聯。這樣，客戶機可使用JSP頁面的普通名稱，但仍然激活定製的版本。例如，給定來自項目1的servlet定義，可使用下面的servlet-mapping定義：
<servlet-mapping>
<servlet-name>PageName</servlet-name>
<url-pattern>/RealPage.jsp</url-pattern>
</servlet-mapping>
3）JSP頁使用jspInit而不是init。自動從JSP頁面建立的servlet或許已經使用了inti方法。因此，使用JSP聲明提供一個init方法是不合法的，必須制定jspInit方法。
爲了說明初始化JSP頁面的過程，程序清單5-9給出了一個名爲InitPage.jsp的JSP頁面，它包含一個jspInit方法且放置於deployDemo Web應用層次結構的頂層。一般，http://host/deployDemo/InitPage.jsp 形式的URL將激活此頁面的不具有初始化參數訪問權的版本，從而將對firstName和emailAddress變量顯示null。但是，web.xml文件（程序清單5-10）分配了一個註冊名，然後將該註冊名與URL模式/InitPage.jsp相關聯。
程序清單5-9 InitPage.jsp
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD><TITLE>JSP Init Test</TITLE></HEAD>
<BODY BGCOLOR="#FDF5E6">
<H2>Init Parameters:</H2>
<UL>
<LI>First name: <%= firstName %>
<LI>Email address: <%= emailAddress %>
</UL>
</BODY></HTML>
<%!
private String firstName, emailAddress;
public void jspInit() {
ServletConfig config = getServletConfig();
firstName = config.getInitParameter("firstName");
emailAddress = config.getInitParameter("emailAddress");
}
%>
程序清單5-10 web.xml（說明JSP頁面的init參數的摘錄）
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- ... -->
<servlet>
<servlet-name>InitPage</servlet-name>
<jsp-file>/InitPage.jsp</jsp-file>
<init-param>
<param-name>firstName</param-name>
<param-value>Bill</param-value>
</init-param>
<init-param>
<param-name>emailAddress</param-name>
<param-value>[email protected]</param-value>
</init-param>
</servlet>
<!-- ... -->
<servlet-mapping>
<servlet-name> InitPage</servlet-name>
<url-pattern>/InitPage.jsp</url-pattern>
</servlet-mapping>
<!-- ... -->
</web-app>
5.3 提供應用範圍內的初始化參數
一般，對單個地servlet或JSP頁面分配初始化參數。指定的servlet或JSP頁面利用ServletConfig的getInitParameter方法讀取這些參數。但是，在某些情形下，希望提供可由任意servlet或JSP頁面藉助ServletContext的getInitParameter方法讀取的系統範圍內的初始化參數。
可利用context-param元素聲明這些系統範圍內的初始化值。context-param元素應該包含param-name、param-value以及可選的description子元素，如下所示：
<context-param>
<param-name>support-email</param-name>
<param-value>[email protected]</param-value>
</context-param>
可回憶一下，爲了保證可移植性，web.xml內的元素必須以正確的次序聲明。但這裏應該注意，context-param元素必須出現任意與文檔有關的元素（icon、display-name或description）之後及filter、filter-mapping、listener或servlet元素之前。
5.4 在服務器啓動時裝載servlet
假如servlet或JSP頁面有一個要花很長時間執行的init（servlet）或jspInit（JSP）方法。例如，假如init或jspInit方法從某個數據庫或ResourceBundle查找產量。這種情況下，在第一個客戶機請求時裝載servlet的缺省行爲將對第一個客戶機產生較長時間的延遲。因此，可利用servlet的load-on-startup元素規定服務器在第一次啓動時裝載servlet。下面是一個例子。
<servlet>
<servlet-name> … </servlet-name>
<servlet-class> … </servlet-class> <!-- Or jsp-file -->
<load-on-startup/>
</servlet>
可以爲此元素體提供一個整數而不是使用一個空的load-on-startup。想法是服務器應該在裝載較大數目的servlet或JSP頁面之前裝載較少數目的servlet或JSP頁面。例如，下面的servlet項（放置在Web應用的WEB-INF目錄下的web.xml文件中的web-app元素內）將指示服務器首先裝載和初始化SearchServlet，然後裝載和初始化由位於Web應用的result目錄中的index.jsp文件產生的servlet。
<servlet>
<servlet-name>Search</servlet-name>
<servlet-class>myPackage.SearchServlet</servlet-class> <!-- Or jsp-file -->
<load-on-startup>1</load-on-startup>
</servlet>
<servlet>
<servlet-name>Results</servlet-name>
<servlet-class>/results/index.jsp</servlet-class> <!-- Or jsp-file -->
<load-on-startup>2</load-on-startup>
</servlet>
6 聲明過濾器
servlet版本2.3引入了過濾器的概念。雖然所有支持servlet API版本2.3的服務器都支持過濾器，但爲了使用與過濾器有關的元素，必須在web.xml中使用版本2.3的DTD。
過濾器可截取和修改進入一個servlet或JSP頁面的請求或從一個servlet或JSP頁面發出的相應。在執行一個servlet或JSP頁面之前，必須執行第一個相關的過濾器的doFilter方法。在該過濾器對其FilterChain對象調用doFilter時，執行鏈中的下一個過濾器。如果沒有其他過濾器，servlet或JSP頁面被執行。過濾器具有對到來的ServletRequest對象的全部訪問權，因此，它們可以查看客戶機名、查找到來的cookie等。爲了訪問servlet或JSP頁面的輸出，過濾器可將響應對象包裹在一個替身對象（stand-in object）中，比方說把輸出累加到一個緩衝區。在調用FilterChain對象的doFilter方法之後，過濾器可檢查緩衝區，如有必要，就對它進行修改，然後傳送到客戶機。
例如，程序清單5-11帝國難以了一個簡單的過濾器，只要訪問相關的servlet或JSP頁面，它就截取請求並在標準輸出上打印一個報告（開發過程中在桌面系統上運行時，大多數服務器都可以使用這個過濾器）。
程序清單5-11 ReportFilter.java
package moreservlets;
import JAVA.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import JAVA.util.*;
/** Simple filter that prints a report on the standard output
* whenever the associated servlet or JSP page is accessed.
* <P>
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class ReportFilter implements Filter {
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain chain)
throws ServletException, IOException {
HttpServletRequest req = (HttpServletRequest)request;
System.out.println(req.getRemoteHost() +
" tried to access " +
req.getRequestURL() +
" on " + new Date() + ".");
chain.doFilter(request,response);
}
public void init(FilterConfig config)
throws ServletException {
}
public void destroy() {}
}
一旦建立了一個過濾器，可以在web.xml中利用filter元素以及filter-name（任意名稱）、file-class（完全限定的類名）和（可選的）init-params子元素聲明它。請注意，元素在web.xml的web-app元素中出現的次序不是任意的；允許服務器（但不是必需的）強制所需的次序，並且實際中有些服務器也是這樣做的。但這裏要注意，所有filter元素必須出現在任意filter-mapping元素之前，filter-mapping元素又必須出現在所有servlet或servlet-mapping元素之前。
例如，給定上述的ReportFilter類，可在web.xml中作出下面的filter聲明。它把名稱Reporter與實際的類ReportFilter（位於moreservlets程序包中）相關聯。
<filter>
<filter-name>Reporter</filter-name>
<filter-class>moresevlets.ReportFilter</filter-class>
</filter>
一旦命名了一個過濾器，可利用filter-mapping元素把它與一個或多個servlet或JSP頁面相關聯。關於此項工作有兩種選擇。
首先，可使用filter-name和servlet-name子元素把此過濾器與一個特定的servlet名（此servlet名必須稍後在相同的web.xml文件中使用servlet元素聲明）關聯。例如，下面的程序片斷指示系統只要利用一個定製的URL訪問名爲SomeServletName的servlet或JSP頁面，就運行名爲Reporter的過濾器。
<filter-mapping>
<filter-name>Reporter</filter-name>
<servlet-name>SomeServletName</servlet-name>
</filter-mapping>
其次，可利用filter-name和url-pattern子元素將過濾器與一組servlet、JSP頁面或靜態內容相關聯。例如，相面的程序片段指示系統只要訪問Web應用中的任意URL，就運行名爲Reporter的過濾器。
<filter-mapping>
<filter-name>Reporter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
例如，程序清單5-12給出了將ReportFilter過濾器與名爲PageName的servlet相關聯的web.xml文件的一部分。名字PageName依次又與一個名爲TestPage.jsp的JSP頁面以及以模式http://host/webAppPrefix/UrlTest2/ 開頭的URL相關聯。TestPage.jsp的源代碼已經JSP頁面命名的談論在前面的3節"分配名稱和定製的URL"中給出。事實上，程序清單5-12中的servlet和servlet-name項從該節原封不動地拿過來的。給定這些web.xml項，可看到下面的標準輸出形式的調試報告（換行是爲了容易閱讀）。
audit.irs.gov tried to access
http://mycompany.com/deployDemo/UrlTest2/business/tax-plan.html
on Tue Dec 25 13:12:29 EDT 2001.
程序清單5-12 Web.xml（說明filter用法的摘錄）
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<filter>
<filter-name>Reporter</filter-name>
<filter-class>moresevlets.ReportFilter</filter-class>
</filter>
<!-- ... -->
<filter-mapping>
<filter-name>Reporter</filter-name>
<servlet-name>PageName</servlet-name>
</filter-mapping>
<!-- ... -->
<servlet>
<servlet-name>PageName</servlet-name>
<jsp-file>/RealPage.jsp</jsp-file>
</servlet>
<!-- ... -->
<servlet-mapping>
<servlet-name> PageName </servlet-name>
<url-pattern>/UrlTest2/*</url-pattern>
</servlet-mapping>
<!-- ... -->
</web-app>
7 指定歡迎頁
假如用戶提供了一個像http://host/webAppPrefix/directoryName/ 這樣的包含一個目錄名但沒有包含文件名的URL，會發生什麼事情呢？用戶能得到一個目錄表？一個錯誤？還是標準文件的內容？如果得到標準文件內容，是index.html、index.jsp、default.html、default.htm或別的什麼東西呢？
Welcome-file-list元素及其輔助的welcome-file元素解決了這個模糊的問題。例如，下面的web.xml項指出，如果一個URL給出一個目錄名但未給出文件名，服務器應該首先試用index.jsp，然後再試用index.html。如果兩者都沒有找到，則結果有賴於所用的服務器（如一個目錄列表）。
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
雖然許多服務器缺省遵循這種行爲，但不一定必須這樣。因此，明確地使用welcom-file-list保證可移植性是一種良好的習慣。
8 指定處理錯誤的頁面
現在我瞭解到，你在開發servlet和JSP頁面時從不會犯錯誤，而且你的所有頁面是那樣的清晰，一般的程序員都不會被它們的搞糊塗。但是，是人總會犯錯誤的，用戶可能會提供不合規定的參數，使用不正確的URL或者不能提供必需的表單字段值。除此之外，其它開發人員可能不那麼細心，他們應該有些工具來克服自己的不足。
error-page元素就是用來克服這些問題的。它有兩個可能的子元素，分別是：error-code和exception-type。第一個子元素error-code指出在給定的HTTP錯誤代碼出現時使用的URL。第二個子元素excpetion-type指出在出現某個給定的Java異常但未捕捉到時使用的URL。error-code和exception-type都利用location元素指出相應的URL。此URL必須以/開始。location所指出的位置處的頁面可通過查找HttpServletRequest對象的兩個專門的屬性來訪問關於錯誤的信息，這兩個屬性分別是：javax.servlet.error.status_code和javax.servlet.error.message。
可回憶一下，在web.xml內以正確的次序聲明web-app的子元素很重要。這裏只要記住，error-page出現在web.xml文件的末尾附近，servlet、servlet-name和welcome-file-list之後即可。
8.1 error-code元素
爲了更好地瞭解error-code元素的值，可考慮一下如果不正確地輸入文件名，大多數站點會作出什麼反映。這樣做一般會出現一個404錯誤信息，它表示不能找到該文件，但幾乎沒提供更多有用的信息。另一方面，可以試一下在www.microsoft.com、www.ibm.com 處或者特別是在www.bea.com 處輸出未知的文件名。這是會得出有用的消息，這些消息提供可選擇的位置，以便查找感興趣的頁面。提供這樣有用的錯誤頁面對於Web應用來說是很有價值得。事實上rm-error-page子元素）。由form-login-page給出的HTML表單必須具有一個j_security_check的ACTION屬性、一個名爲j_username的用戶名文本字段以及一個名爲j_password的口令字段。
例如，程序清單5-19指示服務器使用基於表單的驗證。Web應用的頂層目錄中的一個名爲login.jsp的頁面將收集用戶名和口令，並且失敗的登陸將由相同目錄中名爲login-error.jsp的頁面報告。
程序清單5-19 web.xml（說明login-config的摘錄）
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- ... -->
<security-constraint> ... </security-constraint>
<login-config>
<auth-method> FORM </auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/login-error.jsp</form-error-page>
</form-login-config>
</login-config>
<!-- ... -->
</web-app>
9.2 限制對Web資源的訪問
現在，可以指示服務器使用何種驗證方法了。"了不起，"你說道，"除非我能指定一個來收到保護的URL，否則沒有多大用處。"沒錯。指出這些URL並說明他們應該得到何種保護正是security-constriaint元素的用途。此元素在web.xml中應該出現在login-config的緊前面。它包含是個可能的子元素，分別是：web-resource-collection、auth-constraint、user-data-constraint和display-name。下面各小節對它們進行介紹。
l web-resource-collection
此元素確定應該保護的資源。所有security-constraint元素都必須包含至少一個web-resource-collection項。此元素由一個給出任意標識名稱的web-resource-name元素、一個確定應該保護的URL的url-pattern元素、一個指出此保護所適用的HTTP命令（GET、POST等，缺省爲所有方法）的http-method元素和一個提供資料的可選description元素組成。例如，下面的Web-resource-collection項（在security-constratint元素內）指出Web應用的proprietary目錄中所有文檔應該受到保護。
<security-constraint>
<web-resource-coolection>
<web-resource-name>Proprietary</web-resource-name>
<url-pattern>/propritary/*</url-pattern>
</web-resource-coolection>
<!-- ... -->
</security-constraint>
重要的是應該注意到，url-pattern僅適用於直接訪問這些資源的客戶機。特別是，它不適合於通過MVC體系結構利用RequestDispatcher來訪問的頁面，或者不適合於利用類似jsp:forward的手段來訪問的頁面。這種不勻稱如果利用得當的話很有好處。例如，servlet可利用MVC體系結構查找數據，把它放到bean中，發送請求到從bean中提取數據的JSP頁面並顯示它。我們希望保證決不直接訪問受保護的JSP頁面，而只是通過建立該頁面將使用的bean的servlet來訪問它。url-pattern和auth-contraint元素可通過聲明不允許任何用戶直接訪問JSP頁面來提供這種保證。但是，這種不勻稱的行爲可能讓開發人員放鬆警惕，使他們偶然對應受保護的資源提供不受限制的訪問。
l auth-constraint
儘管web-resource-collention元素質出了哪些URL應該受到保護，但是auth-constraint元素卻指出哪些用戶應該具有受保護資源的訪問權。此元素應該包含一個或多個標識具有訪問權限的用戶類別role-name元素，以及包含（可選）一個描述角色的description元素。例如，下面web.xml中的security-constraint元素部門規定只有指定爲Administrator或Big Kahuna（或兩者）的用戶具有指定資源的訪問權。
<security-constraint>
<web-resource-coolection> ... </web-resource-coolection>
<auth-constraint>
<role-name>administrator</role-name>
<role-name>kahuna</role-name>
</auth-constraint>
</security-constraint>
重要的是認識到，到此爲止，這個過程的可移植部分結束了。服務器怎樣確定哪些用戶處於任何角色以及它怎樣存放用戶的口令，完全有賴於具體的系統。
例如，Tomcat使用install_dir/conf/tomcat-users.xml將用戶名與角色名和口令相關聯，正如下面例子中所示，它指出用戶joe（口令bigshot）和jane（口令enaj）屬於administrator和kahuna角色。
<tomcat-users>
<user name="joe" password="bigshot" roles="administrator,kahuna" />
<user name="jane" password="enaj" roles="kahuna" />
</tomcat-users>
l user-data-constraint
這個可選的元素指出在訪問相關資源時使用任何傳輸層保護。它必須包含一個transport-guarantee子元素（合法值爲NONE、INTEGRAL或CONFIDENTIAL），並且可選地包含一個description元素。transport-guarantee爲NONE值將對所用的通訊協議不加限制。INTEGRAL值表示數據必須以一種防止截取它的人閱讀它的方式傳送。雖然原理上（並且在未來的HTTP版本中），在INTEGRAL和CONFIDENTIAL之間可能會有差別，但在當前實踐中，他們都只是簡單地要求用SSL。例如，下面指示服務器只允許對相關資源做HTTPS連接：
<security-constraint>
<!-- ... -->
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
l display-name
security-constraint的這個很少使用的子元素給予可能由GUI工具使用的安全約束項一個名稱。
9.3 分配角色名
迄今爲止，討論已經集中到完全由容器（服務器）處理的安全問題之上了。但servlet以及JSP頁面也能夠處理它們自己的安全問題。
例如，容器可能允許用戶從bigwig或bigcheese角色訪問一個顯示主管人員額外緊貼的頁面，但只允許bigwig用戶修改此頁面的參數。完成這種更細緻的控制的一種常見方法是調用HttpServletRequset的isUserInRole方法，並據此修改訪問。
Servlet的security-role-ref子元素提供出現在服務器專用口令文件中的安全角色名的一個別名。例如，假如編寫了一個調用request.isUserInRole（"boss"）的servlet，但後來該servlet被用在了一個其口令文件調用角色manager而不是boss的服務器中。下面的程序段使該servlet能夠使用這兩個名稱中的任何一個。
<servlet>
<!-- ... -->
<security-role-ref>
<role-name>boss</role-name> <!-- New alias -->
<role-link>manager</role-link> <!-- Real name -->
</security-role-ref>
</servlet>
也可以在web-app內利用security-role元素提供將出現在role-name元素中的所有安全角色的一個全局列表。分別地生命角色使高級IDE容易處理安全信息。
10 控制會話超時
如果某個會話在一定的時間內未被訪問，服務器可把它扔掉以節約內存。可利用HttpSession的setMaxInactiveInterval方法直接設置個別會話對象的超時值。如果不採用這種方法，則缺省的超時值由具體的服務器決定。但可利用session-config和session-timeout元素來給出一個適用於所有服務器的明確的超時值。超時值的單位爲分鐘，因此，下面的例子設置缺省會話超時值爲三個小時（180分鐘）。
<session-config>
<session-timeout>180</session-timeout>
</session-config>
11 Web應用的文檔化
越來越多的開發環境開始提供servlet和JSP的直接支持。例子有Borland Jbuilder Enterprise Edition、Macromedia UltraDev、Allaire JRun Studio（寫此文時，已被Macromedia收購）以及IBM VisuaAge for Java等。
大量的web.xml元素不僅是爲服務器設計的，而且還是爲可視開發環境設計的。它們包括icon、display-name和discription等。
可回憶一下，在web.xml內以適當地次序聲明web-app子元素很重要。不過，這裏只要記住icon、display-name和description是web.xml的web-app元素內的前三個合法元素即可。
l icon
icon元素指出GUI工具可用來代表Web應用的一個和兩個圖像文件。可利用small-icon元素指定一幅16 x 16的GIF或JPEG圖像，用large-icon元素指定一幅32 x 32的圖像。下面舉一個例子：
<icon>
<small-icon>/images/small-book.gif</small-icon>
<large-icon>/images/tome.jpg</large-icon>
</icon>
l display-name
display-name元素提供GUI工具可能會用來標記此Web應用的一個名稱。下面是個例子。
<display-name>Rare Books</display-name>
l description
description元素提供解釋性文本，如下所示：
<description>
This Web application represents the store developed for
rare-books.com, an online bookstore specializing in rare
and limited-edition books.
</description>
12 關聯文件與MIME類型
服務器一般都具有一種讓Web站點管理員將文件擴展名與媒體相關聯的方法。例如，將會自動給予名爲mom.jpg的文件一個image/jpeg的MIME類型。但是，假如你的Web應用具有幾個不尋常的文件，你希望保證它們在發送到客戶機時分配爲某種MIME類型。mime-mapping元素（具有extension和mime-type子元素）可提供這種保證。例如，下面的代碼指示服務器將application/x-fubar的MIME類型分配給所有以.foo結尾的文件。
<mime-mapping>
<extension>foo</extension>
<mime-type>application/x-fubar</mime-type>
</mime-mapping>
或許，你的Web應用希望重載（override）標準的映射。例如，下面的代碼將告訴服務器在發送到客戶機時指定.ps文件作爲純文本（text/plain）而不是作爲PostScript（application/postscript）。
<mime-mapping>
<extension>ps</extension>
<mime-type>application/postscript</mime-type>
</mime-mapping>
13 定位TLD
JSP taglib元素具有一個必要的uri屬性，它給出一個TLD（Tag Library Descriptor）文件相對於Web應用的根的位置。TLD文件的實際名稱在發佈新的標籤庫版本時可能會改變，但我們希望避免更改所有現有JSP頁面。此外，可能還希望使用保持taglib元素的簡練性的一個簡短的uri。這就是部署描述符文件的taglib元素派用場的所在了。Taglib包含兩個子元素：taglib-uri和taglib-location。taglib-uri元素應該與用於JSP taglib元素的uri屬性的東西相匹配。Taglib-location元素給出TLD文件的實際位置。例如，假如你將文件chart-tags-1.3beta.tld放在WebApp/WEB-INF/tlds中。現在，假如web.xml在web-app元素內包含下列內容。
<taglib>
<taglib-uri>/charts.tld</taglib-uri>
<taglib-location>
/WEB-INF/tlds/chart-tags-1.3beta.tld
</taglib-location>
</taglib>
給出這個說明後，JSP頁面可通過下面的簡化形式使用標籤庫。
<%@ taglib uri="/charts.tld" prefix="somePrefix" %>
14 指定應用事件監聽程序
應用事件監聽器程序是建立或修改servlet環境或會話對象時通知的類。它們是servlet規範的版本2.3中的新內容。這裏只簡單地說明用來向Web應用註冊一個監聽程序的web.xml的用法。
註冊一個監聽程序涉及在web.xml的web-app元素內放置一個listener元素。在listener元素內，listener-class元素列出監聽程序的完整的限定類名，如下所示：
<listener>
<listener-class>package.ListenerClass</listener-class>
</listener>
雖然listener元素的結構很簡單，但請不要忘記，必須正確地給出web-app元素內的子元素的次序。listener元素位於所有的servlet元素之前以及所有filter-mapping元素之後。此外，因爲應用生存期監聽程序是serlvet規範的2.3版本中的新內容，所以必須使用web.xml DTD的2.3版本，而不是2.2版本。
例如，程序清單5-20給出一個名爲ContextReporter的簡單的監聽程序，只要Web應用的Servlet-Context建立（如裝載Web應用）或消除（如服務器關閉）時，它就在標準輸出上顯示一條消息。程序清單5-21給出此監聽程序註冊所需要的web.xml文件的一部分。
程序清單5-20 ContextReporterjava
package moreservlets;
import javax.servlet.*;
import JAVA.util.*;
/** Simple listener that prints a report on the standard output
* when the ServletContext is created or destroyed.
* <P>
* Taken from More Servlets and JavaServer Pages
* from Prentice Hall and Sun Microsystems Press,
* http://www.moreservlets.com/.
* © 2002 Marty Hall; may be freely used or adapted.
*/
public class ContextReporter implements ServletContextListener {
public void contextInitialized(ServletContextEvent event) {
System.out.println("Context created on " +
new Date() + ".");
}
public void contextDestroyed(ServletContextEvent event) {
System.out.println("Context destroyed on " +
new Date() + ".");
}
}
程序清單5-21 web.xml（聲明一個監聽程序的摘錄）
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<!-- ... -->
<filter-mapping> … </filter-mapping>
<listener>
<listener-class>package.ListenerClass</listener-class>
</listener>
<servlet> ... </servlet>
<!-- ... -->
</web-app>
15 J2EE元素
本節描述用作J2EE環境組成部分的Web應用的web.xml元素。這裏將提供一個簡明的介紹，詳細內容可以參閱http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf的Java 2 Plantform Enterprise Edition版本1.3規範的第5章。
l distributable
distributable元素指出，Web應用是以這樣的方式編程的：即，支持集羣的服務器可安全地在多個服務器上分佈Web應用。例如，一個可分佈的應用必須只使用Serializable對象作爲其HttpSession對象的屬性，而且必須避免用實例變量（字段）來實現持續性。distributable元素直接出現在discription元素之後，並且不包含子元素或數據，它只是一個如下的標誌。
<distributable />
l resource-env-ref
resource-env-ref元素聲明一個與某個資源有關的管理對象。此元素由一個可選的description元素、一個resource-env-ref-name元素（一個相對於java:comp/env環境的JNDI名）以及一個resource-env-type元素（指定資源類型的完全限定的類），如下所示：
<resource-env-ref>
<resource-env-ref-name>
jms/StockQueue
</resource-env-ref-name>
<resource-env-ref-type>
javax.jms.Queue
</resource-env-ref-type>
</resource-env-ref>
l env-entry
env-entry元素聲明Web應用的環境項。它由一個可選的description元素、一個env-entry-name元素（一個相對於java:comp/env環境JNDI名）、一個env-entry-value元素（項值）以及一個env-entry-type元素（java.lang程序包中一個類型的完全限定類名，java.lang.Boolean、java.lang.String等）組成。下面是一個例子：
<env-entry>
<env-entry-name>minAmout</env-entry-name>
<env-entry-value>100.00</env-entry-value>
<env-entry-type>minAmout</env-entry-type>
</env-entry>
l ejb-ref
ejb-ref元素聲明對一個EJB的主目錄的應用。它由一個可選的description元素、一個ejb-ref-name元素（相對於java:comp/env的EJB應用）、一個ejb-ref-type元素（bean的類型，Entity或Session）、一個home元素（bean的主目錄接口的完全限定名）、一個remote元素（bean的遠程接口的完全限定名）以及一個可選的ejb-link元素（當前bean鏈接的另一個bean的名稱）組成。
l ejb-local-ref
ejb-local-ref元素聲明一個EJB的本地主目錄的引用。除了用local-home代替home外，此元素具有與ejb-ref元素相同的屬性並以相同的方式使用。
12:29 | 固定鏈接 | 評論 (0) | 引用通告 (0) | 記錄它 | 計算機與 Internet
固定鏈接 關閉
http://spaces.msn.com/members/leizha/Blog/cns!1p7_c76flBEkLNWQcTXG3jeA!116.entry
端口基礎常識大全
端口可分爲3大類：
1） 公認端口（Well Known Ports）：從0到1023，它們緊密綁定於一些服務。通常這些端口的通訊明確表明了某種服務的協議。例如：80端口實際上總是HTTP通訊。
2） 註冊端口（Registered Ports）：從1024到49151。它們鬆散地綁定於一些服務。也就是說有許多服務綁定於這些端口，這些端口同樣用於許多其它目的。例如：許多系統處理動態端口從1024左右開始。
3） 動態和/或私有端口（Dynamic and/or Private Ports）：從49152到65535。理論上，不應爲服務分配這些端口。實際上，機器通常從1024起分配動態端口。但也有例外：SUN的RPC端口從32768開始。
本節講述通常TCP/UDP端口掃描在防火牆記錄中的信息。記住：並不存在所謂ICMP端口。如果你對解讀ICMP數據感興趣，請參看本文的其它部分。
0通常用於分析操作系統。這一方法能夠工作是因爲在一些系統中“0”是無效端口，當你試 圖使用一種通常的閉合端口連接它時將產生不同的結果。一種典型的掃描：使用IP地址爲 0.0.0.0，設置ACK位並在以太網層廣播。
1 tcpmux 這顯示有人在尋找SGIIrix機器。Irix是實現tcpmux的主要提供者，缺省情況下tcpmux在這種系統中被打開。Iris機器在發佈時含有幾個缺省的無密碼的帳戶，如lp,guest, uucp, nuucp, demos, tutor, diag, EZsetup, OutOfBox, 和4Dgifts。許多管理員安裝後忘記刪除這些帳戶。因此Hacker們在Internet上搜索tcpmux 並利用這些帳戶。
7Echo你能看到許多人們搜索Fraggle放大器時，發送到x.x.x.0和x.x.x.255的信息。常見的一種DoS攻擊是echo循環（echo-loop），攻擊者僞造從一個機器發送到另一個UDP數據包，而兩個機器分別以它們最快的方式迴應這些數據包。（參見Chargen） 另一種東西是由DoubleClick在詞端口建立的TCP連接。有一種產品叫做Resonate Global Dispatch”，它與DNS的這一端口連接以確定最近的路由。Harvest/squid cache將從3130端口發送UDPecho：“如果將cache的source_ping on選項打開，它將對原始主機的UDP echo端口迴應一個HIT reply。”這將會產生許多這類數據包。
11 sysstat這是一種UNIX服務，它會列出機器上所有正在運行的進程以及是什麼啓動了這些進程。這爲入侵者提供了許多信息而威脅機器的安全，如暴露已知某些弱點或帳戶的程序。這與UNIX系統中“ps”命令的結果相似再說一遍：ICMP沒有端口，ICMP port 11通常是ICMPtype=1119 chargen 這是一種僅僅發送字符的服務。UDP版本將會在收到UDP包後迴應含有垃圾字符的包。TCP連接時，會發送含有垃圾字符的數據流知道連接關閉。Hacker利用IP欺騙可以發動DoS攻擊僞造兩 個chargen服務器之間的UDP由於服務器企圖迴應兩個服務器之間的無限的往返數據通訊一個chargen和echo將導致服務器過載。同樣fraggle DoS攻擊向目標地址的這個端口廣播一個帶有僞造受害者IP的數據包，受害者爲了迴應這些數據而過載。
21 ftp最常見的攻擊者用於尋找打開“anonymous”的ftp服務器的方法。這些服務器帶有可讀寫的目錄。Hackers或tackers利用這些服務器作爲傳送warez (私有程序) 和pr0n(故意拼錯詞而避免被搜索引擎分類)的節點。
22 sshPcAnywhere建立TCP和這一端口的連接可能是爲了尋找ssh。這一服務有許多弱點。如果配置成特定的模式，許多使用RSAREF庫的版本有不少漏洞。（建議在其它端口運行ssh）還應該注意的是ssh工具包帶有一個稱爲ake-ssh-known-hosts的程序。它會掃描整個域的ssh主機。你有時會被使用這一程序的人無意中掃描到。UDP（而不是TCP）與另一端的5632端口相連意味着存在搜索pcAnywhere的掃描。5632 （十六進制的0x1600）位交換後是0x0016（使進制的22）。
23 Telnet入侵者在搜索遠程登陸UNIX的服務。大多數情況下入侵者掃描這一端口是爲了找到機器運行的操作系統。此外使用其它技術，入侵者會找到密碼。
25 smtp攻擊者（spammer）尋找SMTP服務器是爲了傳遞他們的spam。入侵者的帳戶總被關閉，他們需要撥號連接到高帶寬的e-mail服務器上，將簡單的信息傳遞到不同的地址。SMTP服務器（尤其是sendmail）是進入系統的最常用方法之一，因爲它們必須完整的暴露於Internet且郵件的路由是複雜的（暴露+複雜=弱點）。
53 DNSHacker或crackers可能是試圖進行區域傳遞（TCP），欺騙DNS（UDP）或隱藏其它通訊。因此防火牆常常過濾或記錄53端口。 需要注意的是你常會看到53端口做爲UDP源端口。不穩定的防火牆通常允許這種通訊並假設這是對DNS查詢的回覆。Hacker常使用這種方法穿透防火牆。
67和68 Bootp和DHCPUDP上的Bootp/DHCP：通過DSL和cable-modem的防火牆常會看見大量發送到廣播地址255.255.255.255的數據。這些機器在向DHCP服務器請求一個地址分配。Hacker常進入它們分配一個地址把自己作爲局部路由器而發起大量的“中間人”（man-in-middle）攻擊。客戶端向68端口（bootps）廣播請求配置，服務器向67端口（bootpc）廣播迴應請求。這種迴應使用廣播是因爲客戶端還不知道可以發送的IP地址。
69 TFTP(UDP) 許多服務器與bootp一起提供這項服務，便於從系統下載啓動代碼。但是它們常常錯誤配置而從系統提供任何文件，如密碼文件。它們也可用於向系統寫入文件。
79 finger Hacker用於獲得用戶信息，查詢操作系統，探測已知的緩衝區溢出錯誤，迴應從自己機器到其它機器finger掃描。
98 linuxconf 這個程序提供linuxboxen的簡單管理。通過整合的HTTP服務器在98端口提供基於Web界面的服務。它已發現有許多安全問題。一些版本setuidroot，信任局域網，在/tmp下建立Internet可訪問的文件，LANG環境變量有緩衝區溢出。 此外因爲它包含整合的服務器，許多典型的HTTP漏洞可能存在（緩衝區溢出，歷遍目錄等）
109 POP2並不象POP3那樣有名，但許多服務器同時提供兩種服務（向後兼容）。在同一個服務器上POP3的漏洞在POP2中同樣存在。
110 POP3用於客戶端訪問服務器端的郵件服務。POP3服務有許多公認的弱點。關於用戶名和密碼交換緩衝區溢出的弱點至少有20個（這意味着Hacker可以在真正登陸前進入系統）。成功登陸後還有其它緩衝區溢出錯誤。
111 sunrpc portmap rpcbind Sun RPCPortMapper/RPCBIND。訪問portmapper是掃描系統查看允許哪些RPC服務的最早的一步。常 見RPC服務有：pc.mountd, NFS, rpc.statd, rpc.csmd, rpc.ttybd, amd等。入侵者發現了允許的RPC服務將轉向提供 服務的特定端口測試漏洞。記住一定要記錄線路中的daemon, IDS, 或sniffer，你可以發現入侵者正使用什麼程序訪問以便發現到底發生了什麼。
113 Ident auth .這是一個許多機器上運行的協議，用於鑑別TCP連接的用戶。使用標準的這種服務可以獲得許多機器的信息（會被Hacker利用）。但是它可作爲許多服務的記錄器，尤其是FTP, POP, IMAP, SMTP和IRC等服務。通常如果有許多客戶通過防火牆訪問這些服務，你將會看到許多這個端口的連接請求。記住，如果你阻斷這個端口客戶端會感覺到在防火牆另一邊與e-mail服務器的緩慢連接。許多防火牆支持在TCP連接的阻斷過程中發回T，着將回停止這一緩慢的連接。
119 NNTP news新聞組傳輸協議，承載USENET通訊。當你鏈接到諸如：news:p.security.firewalls/. 的地址時通常使用這個端口。這個端口的連接企圖通常是人們在尋找USENET服務器。多數ISP限制只有他們的客戶才能訪問他們的新聞組服務器。打開新聞組服務器將允許發/讀任何人的帖子，訪問被限制的新聞組服務器，匿名發帖或發送spam。
135 oc-serv MS RPC end-point mapper Microsoft在這個端口運行DCE RPC end- point mapper爲它的DCOM服務。這與UNIX 111端口的功能很相似。使用DCOM和/或RPC的服務利用 機器上的end-point mapper註冊它們的位置。遠端客戶連接到機器時，它們查詢end-point mapper找到服務的位置。同樣Hacker掃描機器的這個端口是爲了找到諸如：這個機器上運 行Exchange Server嗎？是什麼版本？ 這個端口除了被用來查詢服務（如使用epdump）還可以被用於直接攻擊。有一些DoS攻擊直接針對這個端口。
137 NetBIOS name service nbtstat (UDP)這是防火牆管理員最常見的信息，請仔細閱讀文章後面的NetBIOS一節 139 NetBIOS File and Print Sharing 通過這個端口進入的連接試圖獲得NetBIOS/SMB服務。這個協議被用於Windows“文件和打印機共享”和SAMBA。在Internet上共享自己的硬盤是可能是最常見的問題。 大量針對這一端口始於1999，後來逐漸變少。2000年又有回升。一些VBS（IE5 VisualBasicScripting）開始將它們自己拷貝到這個端口，試圖在這個端口繁殖。
143 IMAP和上面POP3的安全問題一樣，許多IMAP服務器有緩衝區溢出漏洞運行登陸過程中進入。記住：一種Linux蠕蟲（admw0rm）會通過這個端口繁殖，因此許多這個端口的掃描來自不知情的已被感染的用戶。當RadHat在他們的Linux發佈版本中默認允許IMAP後，這些漏洞變得流行起來。Morris蠕蟲以後這還是第一次廣泛傳播的蠕蟲。這一端口還被用於IMAP2，但並不流行。 已有一些報道發現有些0到143端口的攻擊源於腳本。
161 SNMP(UDP)入侵者常探測的端口。SNMP允許遠程管理設備。所有配置和運行信息都儲存在數據庫中，通過SNMP客獲得這些信息。許多管理員錯誤配置將它們暴露於Internet。Crackers將試圖使用缺省的密碼“public”“private”訪問系統。他們可能會試驗所有可能的組合。 SNMP包可能會被錯誤的指向你的網絡。Windows機器常會因爲錯誤配置將HP JetDirect rmote management軟件使用SNMP。HP OBJECT IDENTIFIER將收到SNMP包。新版的Win98使用SNMP解析域名，你會看見這種包在子網內廣播（cable modem, DSL）查詢sysName和其它信息。
162 SNMP trap 可能是由於錯誤配置。
177 xdmcp 許多Hacker通過它訪問X-Windows控制檯，它同時需要打開6000端口。
513 rwho 可能是從使用cable modem或DSL登陸到的子網中的UNIX機器發出的廣播。這些人爲Hacker進入他們的系統提供了很有趣的信息。
553 CORBA IIOP (UDP) 如果你使用cable modem或DSL VLAN，你將會看到這個端口的廣播。CORBA是一種面向對象的RPC（remote procedure call）系統。Hacker會利用這些信息進入系統。
600 Pcserver backdoor 請查看1524端口一些玩script的孩子認爲他們通過修改ingreslock和pcserver文件已經完全攻破了系統-- Alan J. Rosenthal.
635 mountd Linux的mountd Bug。這是人們掃描的一個流行的Bug。大多數對這個端口的掃描是基於UDP的，但基於TCP 的mountd有所增加（mountd同時運行於兩個端口）。記住，mountd可運行於任何端口（到底在哪個端口，需要在端口111做portmap查詢），只是Linux默認爲635端口，就象NFS通常運行於2049端口1024 許多人問這個端口是幹什麼的。它是動態端口的開始。許多程序並不在乎用哪個端口連接網絡，它們請求操作系統爲它們分配“下一個閒置端口”。基於這一點分配從端口1024開始。這意味着第一個向系統請求分配動態端口的程序將被分配端口1024。爲了驗證這一點，你可以重啓機器，打開Telnet，再打開一個窗口運行“natstat -a”，你將會看到Telnet被分配1024端口。請求的程序越多，動態端口也越多。操作系統分配的端口將逐漸變大。再來一遍，當你瀏覽Web頁時用“netstat”查看，每個Web頁需要一個新端口。
1080 SOCKS 這一協議以管道方式穿過防火牆，允許防火牆後面的許多人通過一個IP地址訪問Internet。理論上它應該只允許內部的通信向外達到Internet。但是由於錯誤的配置，它會允許Hacker/Cracker的位於防火牆外部的攻擊穿過防火牆。或者簡單地迴應位於Internet上的計算機，從而掩飾他們對你的直接攻擊。WinGate是一種常見的Windows個人防火牆，常會發生上述的錯誤配置。在加入IRC聊天室時常會看到這種情況。
1114 SQL 系統本身很少掃描這個端口，但常常是sscan腳本的一部分。
1524 ingreslock後門 許多攻擊腳本將安裝一個後門Sh*ll 於這個端口（尤其是那些針對Sun系統中Sendmail和RPC服務漏洞的腳本，如statd,ttdbserver和cmsd）。如果你剛剛安裝了你的防火牆就看到在這個端口上的連接企圖，很可能是上述原因。你可以試試Telnet到你的機器上的這個端口，看看它是否會給你一個Sh*ll 。連接到600/pcserver也存在這個問題。
2049 NFS NFS程序常運行於這個端口。通常需要訪問portmapper查詢這個服務運行於哪個端口，可以閉開portmapper直接測試這個端口。
3128 squid 這是Squid HTTP代理服務器的默認端口。攻擊者掃描這個端口是爲了搜尋一個代理服務器而匿名訪問Internet。你也會看到搜索其它代理服務器的端口：
000/8001/8080/8888。掃描這一端口的另一原因是：用戶正在進入聊天室。其它用戶（或服務器本身）也會檢驗這個端口以確定用戶的機器是否支持代理。
5632 pcAnywere你會看到很多這個端口的掃描，這依賴於你所在的位置。當用戶打開pcAnywere時，它會自動掃描局域網C類網以尋找可能得代理（譯者：指agent而不是proxy）。Hacker/cracker也會尋找開放這種服務的機器，所以應該查看這種掃描的源地址。一些搜尋pcAnywere的掃描常包含端口22的UDP數據包。參見撥號掃描。
6776 Sub-7 artifact 這個端口是從Sub-7主端口分離出來的用於傳送數據的端口。例如當控制者通過電話線控制另一臺機器，而被控機器掛斷時你將會看到這種情況。因此當另一人以此IP撥入時，他們將會看到持續的，在這個端口的連接企圖。（譯者：即看到防火牆報告這一端口的連接企圖時，並不表示你已被Sub-7控制。）
6970 RealAudio RealAudio客戶將從服務器的6970-7170的UDP端口接收音頻數據流。這是由TCP7070端口外向控制連接設置13223 PowWow PowWow 是Tribal Voice的聊天程序。它允許用戶在此端口打開私人聊天的接。這一程序對於建立連接非常具有“進攻性”。它會“駐紮”在這一TCP端口等待迴應。這造成類似心跳間隔的連接企圖。如果你是一個撥號用戶，從另一個聊天者手中“繼承”了IP地址這種情況就會發生：好象很多不同的人在測試這一端口。這一協議使用“OPNG”作爲其連接企圖的前四個字節。
17027 Conducent這是一個外向連接。這是由於公司內部有人安裝了帶有Conducent "adbot" 的共享軟件。 Conducent "adbot"是爲共享軟件顯示廣告服務的。使用這種服務的一種流行的軟件是Pkware。有人試驗：阻斷這一外向連接不會有任何問題，但是封掉IP地址本身將會導致adbots持續在每秒內試圖連接多次而導致連接過載： 機器會不斷試圖解析DNS名─ads.conducent.com，即IP地址216.33.210.40 ；
216.33.199.77 ；216.33.199.80 ；216.33.199.81；216.33.210.41。（譯者：不知NetAnts使用的Radiate是否也有這種現象）
30100 NetSphere木馬(TCP) 通常這一端口的掃描是爲了尋找中了NetSphere木馬。
31337 Back Orifice “eliteHacker中31337讀做“elite”/ei’li:t/（譯者：法語，譯爲中堅力量，精華。即 3=E, 1=L, 7=T）。因此許多後門程序運行於這一端口。其中最有名的是Back Orifice。曾經一段時間內這是Internet上最常見的掃描。現在它的流行越來越少，其它的 木馬程序越來越流行。
31789 Hack-a-tack 這一端口的UDP通訊通常是由於"Hack-a-tack"遠程訪問木馬（RAT,Remote Access Trojan）。這種木馬包含內置的31790端口掃描器，因此任何31789端口到317890端口的連 接意味着已經有這種入侵。（31789端口是控制連接，317890端口是文件傳輸連接）
32770~32900 RPC服務 Sun Solaris的RPC服務在這一範圍內。詳細的說：早期版本的Solaris（2.5.1之前）將 portmapper置於這一範圍內，即使低端口被防火牆封閉仍然允許Hacker/cracker訪問這一端口。 掃描這一範圍內的端口不是爲了尋找portmapper，就是爲了尋找可被攻擊的已知的RPC服務。
33434~33600 traceroute 如果你看到這一端口範圍內的UDP數據包（且只在此範圍之內）則可能是由於traceroute。
41508 Inoculan早期版本的Inoculan會在子網內產生大量的UDP通訊用於識別彼此。
端口1~1024是保留端口，所以它們幾乎不會是源端口。但有一些例外，例如來自NAT機器的連接。 常看見緊接着1024的端口，它們是系統分配給那些並不在乎使用哪個端口連接的應用程序的“動態端口”。
Server Client 服務描述
1-5/tcp 動態 FTP 1-5端口意味着sscan腳本
20/tcp 動態 FTP FTP服務器傳送文件的端口
53 動態 FTP DNS從這個端口發送UDP迴應。你也可能看見源/目標端口的TCP連接。
123 動態 S/NTP 簡單網絡時間協議（S/NTP）服務器運行的端口。它們也會發送到這個端口的廣播。
27910~27961/udp 動態 Quake Quake或Quake引擎驅動的遊戲在這一端口運行其服務器。因此來自這一端口範圍的UDP包或發送至這一端口範圍的UDP包通常是遊戲。
