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