注釋的執(zhí)行：
不論你使用注釋與否??尤其在你不使用時??它對于理解服務(wù)器上程序的執(zhí)行有著重要意義。為了讓服務(wù)器識別類中的注釋，它必須加載這些類，這就意味著服務(wù)器必須是啟動著的，服務(wù)器通過WEB-INF/classes目錄下和WEB－INF/lib目錄下的所有類文件來查找注釋。（每個規(guī)范下，服務(wù)器不必查找這兩個目錄以外的目錄。）你可以通過下面的方法指明<web-app>根的屬性而不必使用如何進(jìn)行注釋：
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
version="2.5" full="true">
</web-app>
web.xml的便利：
Servlet2.5對于web.xml引入幾個小的變動，使得它更加方便。
Servlet名稱的通配符化：
首先，當(dāng)你寫<filter-mapping>,你現(xiàn)在可以在<Servlet-name>標(biāo)簽中使用*號來代表所有的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ù)合模式：
其次，當(dāng)我們寫<Servlet-mapping> 或者 <filter-mapping>時，你現(xiàn)在可以在同一的標(biāo)簽中采用復(fù)合匹配的標(biāo)準(zhǔn)。以前一個<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方法名放進(jìn)<http-method>元素中。當(dāng)你使用這些方法時，<http-method>將指明<security-constraint>標(biāo)記里的方法應(yīng)該被應(yīng)用。從以前來看，它僅限于HTTP/1.1的7個標(biāo)準(zhǔn)方法：GET，POST，PUT，DELETE，HEAD，OPTIONS和TRACE。但是，HTTP/1.1允許對方法進(jìn)行擴(kuò)展，WebDAV是用于這種擴(kuò)展的普遍技術(shù)。在Servlet2.5中，你可以安全地約束任何可能的HTTP方法名，標(biāo)準(zhǔn)及擴(kuò)展，包括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)的標(biāo)題頭，而Servlet2.5減弱了這一規(guī)范。原規(guī)范的目的是使內(nèi)部的Servlets限制在自己的頁面空間中，不可以影響外部的頁面。現(xiàn)在這個規(guī)范已經(jīng)減弱，允許在內(nèi)部的Servlet中使用request.getSession()命令，這個命令可以悄悄地創(chuàng)建一個會話跟蹤cookie的標(biāo)題頭。邏輯上要求限制內(nèi)部的資源，但邏輯上也要求這些限制不應(yīng)該取消其啟動session的這一功能。這個變動對于Portlet規(guī)范來說顯得尤其重要。作用是：如果響應(yīng)已經(jīng)有效，則getSession()命令就會拋出一個IllegalStateException(異常)，而在此之前，就沒有這個功能。
優(yōu)化：
最近，新的規(guī)范優(yōu)化了一些實例，使得Servlets更加方便而且保證了更好地按要求工作。
終止響應(yīng)：
第一處優(yōu)化細(xì)小又深奧，但做為規(guī)范中的一個例子還有蠻有趣的。Servlet2.4規(guī)范規(guī)定響應(yīng)在這幾種情況下應(yīng)該是有效的，包括：在響應(yīng)的setContentLength方法中內(nèi)容已經(jīng)明確說明，以及內(nèi)容已經(jīng)寫進(jìn)了響應(yīng)中。這種情況只有你的代碼像下面這樣才可以使響應(yīng)重新定向：
response.setHeader("Host", "localhost")；
response.setHeader("Pragma", "no-cache")；
response.setHeader("Content-Length", "0")；
response.setHeader("Location", "http://www.apache.org")；
Servlet技術(shù)忽略特定區(qū)域的標(biāo)題頭，因為內(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)明確說明。當(dāng)Servlets指派從一個上下文到其他上下文的請求時，這個規(guī)則就發(fā)揮了作用??在目標(biāo)調(diào)用過程中，包括哪些會話。這個版本的出現(xiàn)使得一個上下文目錄的主頁里的portlets可以通過幾種內(nèi)部的命令來對別的上下文目錄里的portlets起作用。Servlet2.5明確指出一個上下文目錄里的資源可以訪問其他上下文目錄的session(會話)，而不用考慮這個請求從哪里開始的。這意味著portlets可以脫離主頁的范圍而在自己的范圍里運行，而且這個規(guī)范還會應(yīng)用在不兼容的Serlvet容器中。
期待：
由于Servlet2.5版本要保持一些舊的性質(zhì)，幾個大的概念不得不延后到下一個階段。它們包括：
"新的輸入/輸出(NIO)支持：使NIO通道更有利于Servlets進(jìn)行客戶端通信成為可能。
"過濾器wrap-under或wrap-over語義：有時用過濾器包裝請求，和/或者響應(yīng)對象去修改方法行為或者啟用新的方法。當(dāng)把這種包裝和服務(wù)器對請求和響應(yīng)的包裝結(jié)合起來時，又應(yīng)該怎么包裝在一起？
"用于歡迎的Servlets文件：做為索引應(yīng)該充當(dāng)歡迎作用的文件嗎？在此之前，這個回答是肯定的。但是規(guī)范沒有明確說明如何使用這個功能，尤其在沒有索引的情況下。
"用于歡迎的文件的分派規(guī)則：如何分派歡迎文件，這個細(xì)節(jié)并沒有完全說明，而是遺留了一些開放的缺口來應(yīng)對不兼容問題。
"登陸后選擇默認(rèn)頁面：如果用戶通過他們的書簽訪問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ù)覽版本，其中最重要的一點是兩者將表達(dá)式語言（ExpressionLanguage，EL）部分合二為一。在不久的將來，這兩種技術(shù)有可能更進(jìn)一步地彼此融合，成為一種統(tǒng)一的表現(xiàn)層技術(shù)。然而在J2EE社群的普遍觀點中，如果單單作為一種視圖技術(shù)，JSP并不是最佳的選擇，Velocity和XSLT等基于模板的視圖技術(shù)通常比JSP更方便；而基于組件的JSF也面臨廣泛的信任危機。兩者的組合是否能得到業(yè)界的認(rèn)可，還需要時間的檢驗。
jsp 2.1
我們很高興向大家宣告，JavaServer Pages、JSR-245下開發(fā)的Faces.JavaServerPages（JSP）2.1和JSR-252下開發(fā)的JavaServer Faces（Faces）1.2的新版規(guī)范的Early DraftReview發(fā)布。
JSP 2.1把ExpressionLanguage（EL）輸出到它自己各自分離的文檔中，在技術(shù)上，這些文檔是JSP規(guī)范的子文檔。這些統(tǒng)一的EL規(guī)范定義了一個更高層的java包，javax.el。這個包與使用它的技術(shù)之間完全獨立，并且允許此技術(shù)將自身插入EL處理過程。更改的JSP規(guī)范遵從使用標(biāo)準(zhǔn)化EL的規(guī)范。
對于前面提到的JSR-252，這個規(guī)范并沒什么新特性。Faces 1.2支持新的標(biāo)準(zhǔn)化EL，還包含一些bug修復(fù)的相關(guān)規(guī)范。
Faces和JSP在JSRs下的結(jié)盟帶來了一些新功能，也為將來的發(fā)展打下了堅實的基礎(chǔ)。例如，在同時使用Faces和JSP的web應(yīng)用中，網(wǎng)頁僅使用JSP（不包含任何faces內(nèi)容）來訪問ManagedBeans成為可能。在JSP規(guī)范的附錄E中和Faces規(guī)范的前言中都可以看到更改內(nèi)容的細(xì)節(jié)。
