2005年9月26日，Sun公司和JSR154的專家組發(fā)布Servlet API的一個新的版本。在一般情況下，一個JSR的新版本僅僅包 括對以前少數(shù)有名無實的規(guī)范進行去除更新。但這次，新版本中增加新的特征和變化，他們對Servlets的產(chǎn)生重要影響，使得Servlet的版本升到了 2.5。
在這篇文章里，我主要談?wù)凷ervlet2.5版本中的新特征。描述每一個變化，闡述那些必要變化產(chǎn)生的背景，并展示如何在基于Servlet的項目中利用這些變化。　
事實上，這是我為JavaWorld提供的第六篇關(guān)于Servlet API更新資料的文章。這篇文章意在兩個目的：從眼前來看，向你介紹 Servlet的新特征。從長遠來看，是展現(xiàn)Servlet變化的歷史概要，這樣當你基于老的Servlet API版本進行編碼的時候，你可以正確地決 定哪些特征和功能你可以使用，而哪些特征和功能你不應(yīng)該使用。你可以參考我先前寫的關(guān)于Servlet的文章。
注意：當你想實踐這些Servlet的新特征和功能時，你要知道的是：并不是所有的Servlet容器和Java企業(yè)級應(yīng)用服務(wù)器都能立即適用于最新 版的Servlet API，寫這篇文章時（2006年1月2日），Jetty 6 server和Sun公司的GlassFish server是公認 最好的支持Servlet2.5的容器，而Apache Tomcat5.5和Jboss 4.0目前只支持Servlet2.4。
Servlet2.5一些變化的介紹：
1）    基于最新的J2SE 5.0開發(fā)的。
2）    支持注釋。
3）    web.xml中的幾處配置更加方便。
4）    去除了少數(shù)的限制。
5）    優(yōu)化了一些實例
J2SE 5.0的產(chǎn)物：
從一開始，Servlet 2.5 規(guī)范就列出J2SE 5.0 (JDK 1.5) 作為它最小的平臺要求。它使得Servlet2.5只能適用基于J2SE 5.0開發(fā)的平臺，這個變動意味著所有J2SE5.0的新特性可以保證對Servlet2.5程序員有用。
傳統(tǒng)意義上，Servlet和JEE版本一直與JDK的版本保持同步發(fā)展，但是這次，Servlet的版本跳過1.4版本。專家組認為版本的加速增長是正當?shù)?，因為J2SE5.0提出一個引人注目的，Servlet和JEE規(guī)范都要利用的特征??注釋。
注釋：
注釋是作為JSR175的一部分提出的（一種為Java語言設(shè)計提供便利的Metadata）一種新的語言特色。它是利用Metadata為Java 編碼結(jié)構(gòu)（類，方法，域等等）裝飾的一種機制。它不能像代碼那樣執(zhí)行，但是可以用于標記代碼，這個過程是基于Metadata信息的代碼處理機，通過更新 他們的事件行為來實現(xiàn)的。

我們可以憑借不同的技巧來注釋類和方法，例如連續(xù)地標記接口或者是@deprecated Javadoc評論。這種新式的Metadata可以便利地提供了一種標準的機制來實現(xiàn)注釋功能，以及通過庫來創(chuàng)建用戶自己的注釋類型的變量。
下面是一個簡單的Web service 注釋例子：
import javax.jws.WebService;
import javax.jws.WebMethod;
@WebService
public class HelloWorldService {
  @WebMethod
  public String helloWorld() {
    return "Hello World!";
  }
}
@WebService和@WebMethod這兩個注釋類型，在JSR181（為Java平臺提供的Web ServicesMetadata）有詳細 說明，可以像類一樣的引用，標記這個類作為一個Web service并且標記它的helloWorld（）方法做為一個Web service方法。對 于他們本身來說，注釋只是寫在那里并沒有什么作用，好像在崗位上做記錄一樣，但是，一個容器一旦加載這個類并對那些注釋進行二進制編碼，就可以把這個類連 到Web service上。
注釋可以接受屬性/值這些參數(shù)。它保存著參數(shù)的信息并且可以利用這些參數(shù)來更改被請求的事件行為。例如下面更高級的注釋例子：
@WebService(
 name = "PingService",
  targetNamespace=http:///ping
)
@SOAPBinding(
  style=SOAPBinding.Style.RPC,
  use=SOAPBinding.Use.LITERAL
)
public class Ping {
  @WebMethod(operationName = "Foo")
  public void foo() { }
}
一旦加載了這個類，一個正確配置的容器就會識別出注釋及其參數(shù)，并將這個做為一個PingService通過利用remote-procedure- call/literal的編碼方式與一個Foo operation相連。實際上，注釋便指明了類和類的容器之間的聯(lián)系。

Java本身的規(guī)范（JSR175）僅僅有少量的注釋類型變量。而這些有趣的注釋類型變量主要來自于其他的JSRs：
"JSR 250: Java平臺的公共注釋
"JSR 220: 企業(yè)級JavaBeans 3.0 
"JSR 224: 基于XML的Java API Web Services (JAX-WS) 2.0 
"JSR 181: Java平臺的Web Services Metadata 
Servlet2.5中的注釋：
回到Servlet2.5上來，一種新的規(guī)范描述了幾種注釋在Servlet環(huán)境中是如何工作的。功能弱的Servlet容器忽略了這些規(guī)范，然而JEE容器中的Servlet卻嚴格遵守這些規(guī)范。

有的注釋提供了在XML注冊的可選擇性，否則就要注冊在配置文件web.xml中。有的作為容器的請求來執(zhí)行其任務(wù)，否則就由Servlet親自來執(zhí)行。還有的注釋兩者都具備。

注釋準確的定義不是完全固定的，因為Servlet本身并沒有定義注釋。它僅僅解釋了它們?nèi)绾斡绊慡ervlet環(huán)境，下面是注釋的一個簡要的概述，你可以看到在JEE5中它們的用途：

"@Resource and @Resources：@Resource位于類或變量中以對Servlet容器進行“資源注入”。當容器識別出這個注釋 時，它會在獲得服務(wù)地位之前，用適當?shù)闹祵崿F(xiàn)帶注釋的變量的重新注入。通過使用這種注釋，你不必利用JNDI來查找命令和在配置文件web.xml中手動 聲明資源。服務(wù)器通過Servlet的自我調(diào)整來執(zhí)行它的任務(wù)。變量的名稱和類型由映像機制自動確定，盡管你可以利用注釋的參數(shù)來超越這一限制。一個注入 的資源可以是數(shù)據(jù)源，Java信息服務(wù)目的文件或者是環(huán)境設(shè)置的標量。下面是一個例子：
@Resource javax.sql.DataSource catalog;
public getData() {
  Connection con = catalog.getConnection();
}
現(xiàn)在，在這段Servlet代碼變成服務(wù)之前，容器會定位JNDI變量，并對于目錄變量進行手動分配。
為了效率，僅僅某些類支持資源注入，這些類有：Servlets，Servlet過濾器，Servlet事件監(jiān)聽器，JSP標簽操作器，JSP庫事件監(jiān)聽器，用于處理beans的JSF，以及一些與Serlvets無關(guān)的類。
"@Resources注釋與@Resource相似，但是它用于一組@Resource注釋。它們都來自JSR250，是Java平臺的公共注釋。
"@PostConstruct and @PreDestroy：可以使方法成為帶有生命周期的方法。@PostConstruct方法用于資源注入初 始化之后。@PreDestroy方法用于Servlet脫離服務(wù)并釋放注入的資源的時候?；厥盏姆椒ū仨毷鞘聦嵉姆椒ǎ祷豽oid并且不可以拋出任何 異常。這些注釋本質(zhì)上使得任何方法都成為init()和destroy()的子方法，這些特征也來自與JSR250。
"@EJB：類似于@Resource，設(shè)計用于注入企業(yè)級的JavaBeans。比起@Resource，它略有不同，在于@EJB的參數(shù)特定設(shè)計用來定位EJB的參數(shù)。這個注釋來自EJB3.0的規(guī)范。
"@WebServiceRef：與@Resource 和 @EJB相似，設(shè)計用于注入Web service參數(shù)。來自于JAX-WS2.0規(guī)范。
"@PersistenceContext, @PersistenceContexts, @PersistenceUnit, and @PersistenceUnits：這些注釋來自EJB3.0規(guī)范來支持Java對象的持久化。
"@DeclareRoles: 定義應(yīng)用程序中安全角色的使用。當定義一個Servlet類時，在配置文件web.xml中<security-role>標簽中對它進行設(shè)置，來自JSR250。
" @RunAs：用于聲明哪個類應(yīng)該執(zhí)行。當定義一個Servlet類時，在配置文件web.xml中<run-as>標簽中對它進行設(shè)置。來自于JSR250。

注釋的執(zhí)行：
不論你使用注釋與否??尤其在你不使用時??它對于理解服務(wù)器上程序的執(zhí)行有著重要意義。為了讓服務(wù)器識別類中的注釋，它必須加載這些類，這就意味著 服務(wù)器必須是啟動著的，服務(wù)器通過WEB-INF/classes目錄下和WEB－INF/lib目錄下的所有類文件來查找注釋。（每個規(guī)范下，服務(wù)器不 必查找這兩個目錄以外的目錄。）你可以通過下面的方法指明<web-app>根的屬性而不必使用如何進行注釋：
<web-app xmlns="http://java./xml/ns/javaee"
             version="2.5" full="true">
</web-app>
web.xml的便利：
Servlet2.5對于web.xml引入幾個小的變動，使得它更加方便。
Servlet名稱的通配符化：
首先，當你寫<filter-mapping>,你現(xiàn)在可以在<Servlet-name>標簽中使用*號來代表所有的Servlets。而以前，你必須一次把一個Servlet綁定到過濾器上，像這樣：

<filter-mapping>
  <filter-name>Image Filter</filter-name>
  <Servlet-name>ImageServlet</Servlet-name>
</filter-mapping> 

現(xiàn)在，你可以一次綁定所有的Servlets：

<filter-mapping>
  <filter-name>Image Filter</filter-name>
  <Servlet-name>*</Servlet-name>  <!?新特征 -->
</filter-mapping>

這有著很大用途，例如：

<filter-mapping>
  <filter-name>Dispatch Filter</filter-name>
  <Servlet-name>*</Servlet-name>
  <dispatcher>FORWARD</dispatcher>
</filter-mapping>

映射的復(fù)合模式：
其次，當我們寫<Servlet-mapping> 或者 <filter-mapping>時，你現(xiàn)在可以在同一的標簽中采用 復(fù)合匹配的標準。以前一個<Servlet-mapping>只支持一個<url-pattern>元素，現(xiàn)在它不只支持一個， 例如：
<Servlet-mapping>
  <Servlet-name>color</Servlet-name>
  <url-pattern>/color/*</url-pattern>
  <url-pattern>/colour/*</url-pattern>
</Servlet-mapping>

同樣地，以前<filter-mapping>也是只支持一個<url-pattern> 或者一個 <Servlet-name>?，F(xiàn)在它對于每個元素都可以支持任意多個：

<filter-mapping>
  <filter-name>Multipe Mappings Filter</filter-name>
  <url-pattern>/foo/*</url-pattern>
  <Servlet-name>Servlet1</Servlet-name>
  <Servlet-name>Servlet2</Servlet-name>
  <url-pattern>/bar/*</url-pattern>
</filter-mapping>

HTTP方法名：

最近，你可以將合法的HTTP/1.1方法名放進<http-method>元素中。當你使用這些方法時，<http- method>將指明<security-constraint>標記里的方法應(yīng)該被應(yīng)用。從以前來看，它僅限于HTTP/1.1的7 個標準方法：GET，POST，PUT，DELETE，HEAD，OPTIONS和TRACE。但是，HTTP/1.1允許對方法進行擴展，WebDAV 是用于這種擴展的普遍技術(shù)。在Servlet2.5中，你可以安全地約束任何可能的HTTP方法名，標準及擴展，包括WebDAV方法，例如：LOCK， UNLOCK，COPY及MOVE。
如果你寫一個WebDAV的Servlet，你不必使用doLock()和doCopy()方法。你必須寫自己的service()方法及分派request.getMethod()方法。正由于這種變化，你不必管理系統(tǒng)的安全性。
去除限制：

Servlet2.5去除了關(guān)于錯誤處理和回話跟蹤的一些限制。對于錯誤處理，Servlet2.5之前，配置在<error- page>中的錯誤處理頁面不能通過調(diào)用setStatus()方法來修改觸發(fā)他們的錯誤代碼，而Servlet2.5減弱了這一規(guī)范。這樣的規(guī)范 的產(chǎn)生于這樣的觀點，就是錯誤頁面的工作是指出每個錯誤而不是修改錯誤。但是，實際使用中，錯誤頁面不只是用于指出錯誤，而是還能做更多的事情，或許可以 代替在線幫助來幫助用戶解決問題。這個規(guī)范將不再限制錯誤頁面所產(chǎn)生的反饋信息。

對于會話跟蹤，Servlet2.5之前，調(diào)用RequestDispatcher.include()的Servlet不能設(shè)置響應(yīng)的標題頭，而 Servlet2.5減弱了這一規(guī)范。原規(guī)范的目的是使內(nèi)部的Servlets限制在自己的頁面空間中，不可以影響外部的頁面。現(xiàn)在這個規(guī)范已經(jīng)減弱，允 許在內(nèi)部的Servlet中使用request.getSession()命令，這個命令可以悄悄地創(chuàng)建一個會話跟蹤cookie的標題頭。邏輯上要求限 制內(nèi)部的資源，但邏輯上也要求這些限制不應(yīng)該取消其啟動session的這一功能。這個變動對于Portlet規(guī)范來說顯得尤其重要。作用是：如果響應(yīng)已 經(jīng)有效，則getSession()命令就會拋出一個IllegalStateException(異常)，而在此之前，就沒有這個功能。

優(yōu)化：
最近，新的規(guī)范優(yōu)化了一些實例，使得Servlets更加方便而且保證了更好地按要求工作。

終止響應(yīng)：
第一處優(yōu)化細小又深奧，但做為規(guī)范中的一個例子還有蠻有趣的。Servlet2.4規(guī)范規(guī)定響應(yīng)在這幾種情況下應(yīng)該是有效的，包括：在響應(yīng)的 setContentLength方法中內(nèi)容已經(jīng)明確說明，以及內(nèi)容已經(jīng)寫進了響應(yīng)中。這種情況只有你的代碼像下面這樣才可以使響應(yīng)重新定向：

response.setHeader("Host", "localhost")；
response.setHeader("Pragma", "no-cache")；
response.setHeader("Content-Length", "0")；
response.setHeader("Location", "http://www.")；

Servlet技術(shù)忽略特定區(qū)域的標題頭，因為內(nèi)容滿足0字節(jié)長度，響應(yīng)就會立即生效。而在它開始之前，響應(yīng)就已失效了！Servlet容器通常拒絕執(zhí)行這種行為，而Servlet2.5版本增加了“長度必須大于0”這個原則。
實例編碼：

Servlet2.4規(guī)范規(guī)定必須在調(diào)用request.getReader()方法之前調(diào)用 request.setCharacterEncoding()方法。但是，如果你忽略這個原則而在其之后去調(diào)用 request.setCharacterEncoding()方法，那么會產(chǎn)生什么后果，這個問題規(guī)范里并沒有說。為了簡便，現(xiàn)在消除這種情況！
Cross-context sessions(不同上下文目錄間的會話)：
最近，關(guān)于Cross-context會話處理的規(guī)則已經(jīng)明確說明。當Servlets指派從一個上下文到其他上下文的請求時，這個規(guī)則就發(fā)揮了作 用??在目標調(diào)用過程中，包括哪些會話。這個版本的出現(xiàn)使得一個上下文目錄的主頁里的portlets可以通過幾種內(nèi)部的命令來對別的上下文目錄里的 portlets起作用。Servlet2.5明確指出一個上下文目錄里的資源可以訪問其他上下文目錄的session(會話)，而不用考慮這個請求從哪 里開始的。這意味著portlets可以脫離主頁的范圍而在自己的范圍里運行，而且這個規(guī)范還會應(yīng)用在不兼容的Serlvet容器中。
期待：

由于Servlet2.5版本要保持一些舊的性質(zhì)，幾個大的概念不得不延后到下一個階段。它們包括：
"新的輸入/輸出(NIO)支持：使NIO通道更有利于Servlets進行客戶端通信成為可能。
"過濾器wrap-under或wrap-over語義：有時用過濾器包裝請求，和/或者響應(yīng)對象去修改方法行為或者啟用新的方法。當把這種包裝和服務(wù)器對請求和響應(yīng)的包裝結(jié)合起來時，又應(yīng)該怎么包裝在一起？
"用于歡迎的Servlets文件：做為索引應(yīng)該充當歡迎作用的文件嗎？在此之前，這個回答是肯定的。但是規(guī)范沒有明確說明如何使用這個功能，尤其在沒有索引的情況下。
"用于歡迎的文件的分派規(guī)則：如何分派歡迎文件，這個細節(jié)并沒有完全說明，而是遺留了一些開放的缺口來應(yīng)對不兼容問題。
"登陸后選擇默認頁面：如果用戶通過他們的書簽訪問Servlet的登陸頁面，那么在成功登陸后頁面應(yīng)該轉(zhuǎn)向哪里呢？這個問題至今尚未明確說明。
"用戶的主題日志：在通過網(wǎng)站正確地注冊之后，不通過傳統(tǒng)地登陸方式?jīng)]有辦法使Servlet信任用戶。
結(jié)束語：
如果拋開注釋來看Servlet2.5的變化，可見在配置文件web.xml中去除了一些限制，是有利的，同時又優(yōu)化了實例行為使其更適合更便于開發(fā)Web系統(tǒng)(網(wǎng)頁)。
Servlet2.5中注釋的作用更加戲劇化。Servlets本身不能聲明注釋類型的變量，甚至性能弱的Servlet容器都不支持注釋。然而在 JEE5環(huán)境下的Servlets編寫者可以看到，通過公共的注釋及EJB3.0和JAX-WS2.0規(guī)范而引入的注釋類型會對代碼產(chǎn)生很大變化，并且這 也將對Servlet如何管理外部資源，對象的持久化及EJB的構(gòu)成產(chǎn)生重大影響

J2EE的兩種重要的表現(xiàn)層技術(shù)JSP和JSF發(fā)布了新技術(shù)規(guī)范的預(yù)覽版本，其中最重要的一點是兩者將表達式語言（Expression Language，EL）部分合二為一。在不久的將來，這兩種技術(shù)有可能更進一步地彼此融合，成為一種統(tǒng)一的表現(xiàn)層技術(shù)。然而在J2EE社群的普遍觀點 中，如果單單作為一種視圖技術(shù)，JSP并不是最佳的選擇，Velocity和XSLT等基于模板的視圖技術(shù)通常比JSP更方便；而基于組件的JSF也面臨 廣泛的信任危機。兩者的組合是否能得到業(yè)界的認可，還需要時間的檢驗。

jsp 2.1

    我們很高興向大家宣告，JavaServer Pages、JSR-245下開發(fā)的Faces.JavaServer Pages（JSP）2.1和JSR-252下開發(fā)的JavaServer Faces（Faces）1.2的新版規(guī)范的Early Draft Review發(fā)布。

    JSP 2.1把Expression Language（EL）輸出到它自己各自分離的文檔中，在技術(shù)上，這些文檔是JSP規(guī)范的子文檔。這些統(tǒng)一的EL規(guī)范定義了一個更高層的java 包，javax.el。這個包與使用它的技術(shù)之間完全獨立，并且允許此技術(shù)將自身插入EL處理過程。更改的JSP規(guī)范遵從使用標準化EL的規(guī)范。

    對于前面提到的JSR-252，這個規(guī)范并沒什么新特性。Faces 1.2支持新的標準化EL，還包含一些bug修復(fù)的相關(guān)規(guī)范。

    Faces和JSP在JSRs下的結(jié)盟帶來了一些新功能，也為將來的發(fā)展打下了堅實的基礎(chǔ)。例如，在同時使用Faces和JSP的web應(yīng)用中，網(wǎng)頁僅使 用JSP（不包含任何faces內(nèi)容）來訪問Managed Beans成為可能。在JSP規(guī)范的附錄E中和Faces規(guī)范的前言中都可以看到更改內(nèi)容的細節(jié)。