2005年9月26日，Sun公司和JSR154的專家組發布Servlet API的一個新的版本。在一般情況下，一個JSR的新版本僅僅包括對以前少數有名無實的規范進行去除更新。但這次，新版本中增加新的特征和變化，他們對Servlets的產生重要影響，使得Servlet的版本升到了 2.5。
在這篇文章里，我主要談談Servlet2.5版本中的新特征。描述每一個變化，闡述那些必要變化產生的背景，并展示如何在基于Servlet的項目中利用這些變化。
事實上，這是我為JavaWorld提供的第六篇關于Servlet API更新資料的文章。這篇文章意在兩個目的：從眼前來看，向你介紹 Servlet的新特征。從長遠來看，是展現Servlet變化的歷史概要，這樣當你基于老的Servlet API版本進行編碼的時候，你可以正確地決定哪些特征和功能你可以使用，而哪些特征和功能你不應該使用。你可以參考我先前寫的關于Servlet的文章。
注意：當你想實踐這些Servlet的新特征和功能時，你要知道的是：并不是所有的Servlet容器和Java企業級應用服務器都能立即適用于最新版的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開發的。
2） 支持注釋。
3） web.xml中的幾處配置更加方便。
4） 去除了少數的限制。
5） 優化了一些實例
J2SE 5.0的產物：從一開始，Servlet 2.5 規范就列出J2SE 5.0 (JDK 1.5) 作為它最小的平臺要求。它使得Servlet2.5只能適用基于J2SE 5.0開發的平臺，這個變動意味著所有J2SE5.0的新特性可以保證對Servlet2.5程序員有用。
傳統意義上，Servlet和JEE版本一直與JDK的版本保持同步發展，但是這次，Servlet的版本跳過1.4版本。專家組認為版本的加速增長是正當的，因為J2SE5.0提出一個引人注目的，Servlet和JEE規范都要利用的特征??注釋。
注釋：注釋是作為JSR175的一部分提出的（一種為Java語言設計提供便利的Metadata）一種新的語言特色。它是利用Metadata為Java 編碼結構（類，方法，域等等）裝飾的一種機制。它不能像代碼那樣執行，但是可以用于標記代碼，這個過程是基于Metadata信息的代碼處理機，通過更新他們的事件行為來實現的。
我們可以憑借不同的技巧來注釋類和方法，例如連續地標記接口或者是@deprecated Javadoc評論。這種新式的Metadata可以便利地提供了一種標準的機制來實現注釋功能，以及通過庫來創建用戶自己的注釋類型的變量。
下面是一個簡單的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上。
注釋可以接受屬性/值這些參數。它保存著參數的信息并且可以利用這些參數來更改被請求的事件行為。例如下面更高級的注釋例子：
@WebService(
name = "PingService",
targetNamespace=http://acme.com/ping
)
@SOAPBinding(
style=SOAPBinding.Style.RPC,
use=SOAPBinding.Use.LITERAL
)
public class Ping {
@WebMethod(operationName = "Foo")
public void foo() { }
}
一旦加載了這個類，一個正確配置的容器就會識別出注釋及其參數，并將這個做為一個PingService通過利用remote-procedure- call/literal的編碼方式與一個Foo operation相連。實際上，注釋便指明了類和類的容器之間的聯系。
Java本身的規范（JSR175）僅僅有少量的注釋類型變量。而這些有趣的注釋類型變量主要來自于其他的JSRs：
"JSR 250: Java平臺的公共注釋
"JSR 220: 企業級JavaBeans 3.0
"JSR 224: 基于XML的Java API Web Services (JAX-WS) 2.0
"JSR 181: Java平臺的Web Services Metadata
Servlet2.5中的注釋：
回到Servlet2.5上來，一種新的規范描述了幾種注釋在Servlet環境中是如何工作的。功能弱的Servlet容器忽略了這些規范，然而JEE容器中的Servlet卻嚴格遵守這些規范。
有的注釋提供了在XML注冊的可選擇性，否則就要注冊在配置文件web.xml中。有的作為容器的請求來執行其任務，否則就由Servlet親自來執行。還有的注釋兩者都具備。
注釋準確的定義不是完全固定的，因為Servlet本身并沒有定義注釋。它僅僅解釋了它們如何影響Servlet環境，下面是注釋的一個簡要的概述，你可以看到在JEE5中它們的用途：
"@Resource and @Resources：@Resource位于類或變量中以對Servlet容器進行“資源注入”。當容器識別出這個注釋時，它會在獲得服務地位之前，用適當的值實現帶注釋的變量的重新注入。通過使用這種注釋，你不必利用JNDI來查找命令和在配置文件web.xml中手動聲明資源。服務器通過Servlet的自我調整來執行它的任務。變量的名稱和類型由映像機制自動確定，盡管你可以利用注釋的參數來超越這一限制。一個注入的資源可以是數據源，Java信息服務目的文件或者是環境設置的標量。下面是一個例子：
@Resource javax.sql.DataSource catalog;
public getData() {
Connection con = catalog.getConnection();
}
現在，在這段Servlet代碼變成服務之前，容器會定位JNDI變量，并對于目錄變量進行手動分配。
為了效率，僅僅某些類支持資源注入，這些類有：Servlets，Servlet過濾器，Servlet事件監聽器，JSP標簽操作器，JSP庫事件監聽器，用于處理beans的JSF，以及一些與Serlvets無關的類。
"@Resources注釋與@Resource相似，但是它用于一組@Resource注釋。它們都來自JSR250，是Java平臺的公共注釋。
"@PostConstruct and @PreDestroy：可以使方法成為帶有生命周期的方法。@PostConstruct方法用于資源注入初始化之后。@PreDestroy方法用于Servlet脫離服務并釋放注入的資源的時候。回收的方法必須是事實的方法，返回void并且不可以拋出任何異常。這些注釋本質上使得任何方法都成為init()和destroy()的子方法，這些特征也來自與JSR250。
"@EJB：類似于@Resource，設計用于注入企業級的JavaBeans。比起@Resource，它略有不同，在于@EJB的參數特定設計用來定位EJB的參數。這個注釋來自EJB3.0的規范。
"@WebServiceRef：與@Resource 和 @EJB相似，設計用于注入Web service參數。來自于JAX-WS2.0規范。
"@PersistenceContext, @PersistenceContexts, @PersistenceUnit, and @PersistenceUnits：這些注釋來自EJB3.0規范來支持Java對象的持久化。
"@DeclareRoles: 定義應用程序中安全角色的使用。當定義一個Servlet類時，在配置文件web.xml中<security-role>標簽中對它進行設置，來自JSR250。
" @RunAs：用于聲明哪個類應該執行。當定義一個Servlet類時，在配置文件web.xml中<run-as>標簽中對它進行設置。來自于JSR250。
注釋的執行：
不論你使用注釋與否??尤其在你不使用時??它對于理解服務器上程序的執行有著重要意義。為了讓服務器識別類中的注釋，它必須加載這些類，這就意味著服務器必須是啟動著的，服務器通過WEB-INF/classes目錄下和WEB－INF/lib目錄下的所有類文件來查找注釋。（每個規范下，服務器不必查找這兩個目錄以外的目錄。）你可以通過下面的方法指明<web-app>根的屬性而不必使用如何進行注釋：
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
version="2.5" full="true">
</web-app>
web.xml的便利：
Servlet2.5對于web.xml引入幾個小的變動，使得它更加方便。
Servlet名稱的通配符化：
首先，當你寫<filter-mapping>,你現在可以在<Servlet-name>標簽中使用*號來代表所有的Servlets。而以前，你必須一次把一個Servlet綁定到過濾器上，像這樣：
<filter-mapping>
<filter-name>Image Filter</filter-name>
<Servlet-name>ImageServlet</Servlet-name>
</filter-mapping>
現在，你可以一次綁定所有的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>
映射的復合模式：
其次，當我們寫<Servlet-mapping> 或者 <filter-mapping>時，你現在可以在同一的標簽中采用復合匹配的標準。以前一個<Servlet-mapping>只支持一個<url-pattern>元素，現在它不只支持一個，例如：
<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>。現在它對于每個元素都可以支持任意多個：
<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>標記里的方法應該被應用。從以前來看，它僅限于HTTP/1.1的7 個標準方法：GET，POST，PUT，DELETE，HEAD，OPTIONS和TRACE。但是，HTTP/1.1允許對方法進行擴展，WebDAV 是用于這種擴展的普遍技術。在Servlet2.5中，你可以安全地約束任何可能的HTTP方法名，標準及擴展，包括WebDAV方法，例如：LOCK， UNLOCK，COPY及MOVE。
如果你寫一個WebDAV的Servlet，你不必使用doLock()和doCopy()方法。你必須寫自己的service()方法及分派request.getMethod()方法。正由于這種變化，你不必管理系統的安全性。
去除限制：
Servlet2.5去除了關于錯誤處理和回話跟蹤的一些限制。對于錯誤處理，Servlet2.5之前，配置在<error- page>中的錯誤處理頁面不能通過調用setStatus()方法來修改觸發他們的錯誤代碼，而Servlet2.5減弱了這一規范。這樣的規范的產生于這樣的觀點，就是錯誤頁面的工作是指出每個錯誤而不是修改錯誤。但是，實際使用中，錯誤頁面不只是用于指出錯誤，而是還能做更多的事情，或許可以代替在線幫助來幫助用戶解決問題。這個規范將不再限制錯誤頁面所產生的反饋信息。
對于會話跟蹤，Servlet2.5之前，調用RequestDispatcher.include()的Servlet不能設置響應的標題頭，而 Servlet2.5減弱了這一規范。原規范的目的是使內部的Servlets限制在自己的頁面空間中，不可以影響外部的頁面。現在這個規范已經減弱，允許在內部的Servlet中使用request.getSession()命令，這個命令可以悄悄地創建一個會話跟蹤cookie的標題頭。邏輯上要求限制內部的資源，但邏輯上也要求這些限制不應該取消其啟動session的這一功能。這個變動對于Portlet規范來說顯得尤其重要。作用是：如果響應已經有效，則getSession()命令就會拋出一個IllegalStateException(異常)，而在此之前，就沒有這個功能。
優化：
最近，新的規范優化了一些實例，使得Servlets更加方便而且保證了更好地按要求工作。
終止響應：
第一處優化細小又深奧，但做為規范中的一個例子還有蠻有趣的。Servlet2.4規范規定響應在這幾種情況下應該是有效的，包括：在響應的 setContentLength方法中內容已經明確說明，以及內容已經寫進了響應中。這種情況只有你的代碼像下面這樣才可以使響應重新定向：
response.setHeader("Host", "localhost")；
response.setHeader("Pragma", "no-cache")；
response.setHeader("Content-Length", "0")；
response.setHeader("Location", "http://www.apache.org")；
Servlet技術忽略特定區域的標題頭，因為內容滿足0字節長度，響應就會立即生效。而在它開始之前，響應就已失效了！Servlet容器通常拒絕執行這種行為，而Servlet2.5版本增加了“長度必須大于0”這個原則。
實例編碼：
Servlet2.4規范規定必須在調用request.getReader()方法之前調用 request.setCharacterEncoding()方法。但是，如果你忽略這個原則而在其之后去調用 request.setCharacterEncoding()方法，那么會產生什么后果，這個問題規范里并沒有說。為了簡便，現在消除這種情況！
Cross-context sessions(不同上下文目錄間的會話)：
最近，關于Cross-context會話處理的規則已經明確說明。當Servlets指派從一個上下文到其他上下文的請求時，這個規則就發揮了作用??在目標調用過程中，包括哪些會話。這個版本的出現使得一個上下文目錄的主頁里的portlets可以通過幾種內部的命令來對別的上下文目錄里的 portlets起作用。Servlet2.5明確指出一個上下文目錄里的資源可以訪問其他上下文目錄的session(會話)，而不用考慮這個請求從哪里開始的。這意味著portlets可以脫離主頁的范圍而在自己的范圍里運行，而且這個規范還會應用在不兼容的Serlvet容器中。
期待：
由于Servlet2.5版本要保持一些舊的性質，幾個大的概念不得不延后到下一個階段。它們包括：
"新的輸入/輸出(NIO)支持：使NIO通道更有利于Servlets進行客戶端通信成為可能。
"過濾器wrap-under或wrap-over語義：有時用過濾器包裝請求，和/或者響應對象去修改方法行為或者啟用新的方法。當把這種包裝和服務器對請求和響應的包裝結合起來時，又應該怎么包裝在一起？
"用于歡迎的Servlets文件：做為索引應該充當歡迎作用的文件嗎？在此之前，這個回答是肯定的。但是規范沒有明確說明如何使用這個功能，尤其在沒有索引的情況下。
"用于歡迎的文件的分派規則：如何分派歡迎文件，這個細節并沒有完全說明，而是遺留了一些開放的缺口來應對不兼容問題。
"登陸后選擇默認頁面：如果用戶通過他們的書簽訪問Servlet的登陸頁面，那么在成功登陸后頁面應該轉向哪里呢？這個問題至今尚未明確說明。
"用戶的主題日志：在通過網站正確地注冊之后，不通過傳統地登陸方式沒有辦法使Servlet信任用戶。
結束語：
如果拋開注釋來看Servlet2.5的變化，可見在配置文件web.xml中去除了一些限制，是有利的，同時又優化了實例行為使其更適合更便于開發Web系統(網頁)。
Servlet2.5中注釋的作用更加戲劇化。Servlets本身不能聲明注釋類型的變量，甚至性能弱的Servlet容器都不支持注釋。然而在 JEE5環境下的Servlets編寫者可以看到，通過公共的注釋及EJB3.0和JAX-WS2.0規范而引入的注釋類型會對代碼產生很大變化，并且這也將對Servlet如何管理外部資源，對象的持久化及EJB的構成產生重大影響
J2EE的兩種重要的表現層技術JSP和JSF發布了新技術規范的預覽版本，其中最重要的一點是兩者將表達式語言（Expression Language，EL）部分合二為一。在不久的將來，這兩種技術有可能更進一步地彼此融合，成為一種統一的表現層技術。然而在J2EE社群的普遍觀點中，如果單單作為一種視圖技術，JSP并不是最佳的選擇，Velocity和XSLT等基于模板的視圖技術通常比JSP更方便；而基于組件的JSF也面臨廣泛的信任危機。兩者的組合是否能得到業界的認可，還需要時間的檢驗。
jsp 2.1
我們很高興向大家宣告，JavaServer Pages、JSR-245下開發的Faces.JavaServer Pages（JSP）2.1和JSR-252下開發的JavaServer Faces（Faces）1.2的新版規范的Early Draft Review發布。
JSP 2.1把Expression Language（EL）輸出到它自己各自分離的文檔中，在技術上，這些文檔是JSP規范的子文檔。這些統一的EL規范定義了一個更高層的java 包，javax.el。這個包與使用它的技術之間完全獨立，并且允許此技術將自身插入EL處理過程。更改的JSP規范遵從使用標準化EL的規范。
對于前面提到的JSR-252，這個規范并沒什么新特性。Faces 1.2支持新的標準化EL，還包含一些bug修復的相關規范。
Faces和JSP在JSRs下的結盟帶來了一些新功能，也為將來的發展打下了堅實的基礎。例如，在同時使用Faces和JSP的web應用中，網頁僅使用JSP（不包含任何faces內容）來訪問Managed Beans成為可能。在JSP規范的附錄E中和Faces規范的前言中都可以看到更改內容的細節。