【導讀】設計(論文)題目圖書管理系統(tǒng)。院系計算機科學與工程學院。專業(yè)計算機科學與技術

　　

【正文】 Java 代碼。它使用 .jsp的后綴，用來告訴服務器這個文件需要特殊的處理。當我們訪問一個JSP頁面的時候，這個文件首先會被 JSP引擎翻譯為一個 Java源文件，其實就是一個Servlet，并進行編譯，然后像其他 Servlet一樣，由 Servlet引擎來處理。 Servlet引擎裝載這個類，處理來自客戶的請求，并把結果返回給客戶 。 以后再有客戶訪問這個頁面的時候，只要該文件沒有發(fā)生過更改， JSP 引擎就直接調(diào)用已經(jīng)裝載的 Servlet。如果已經(jīng)做過修改的話，那就會再次執(zhí)行以上過程，翻譯、編譯并裝載。其實這就是所謂的“第一人懲罰”。因為首次訪問的時候要執(zhí)行一系列以上的過程，所以會耗費一些時間；以后的訪問就不會這樣了。 Java servlet提供了一種強有力的 API，用這個 API可以訪問關于請求、會話和應用程序的所有信息。將 servlet 和 JSP 頁面組合起來使用，可以把應用程序的邏輯部分和外觀呈現(xiàn)部分清楚地分開；換句話，利用這個方式可以對模型、視圖和控制器這三種角色分別使用最合適的組件類型 。 15 Servlet、過濾器和監(jiān)聽器 Servlet 是一種 Java 類，它使得服務器的功能可擴展至處理請求和生成應答。它是用 Servlet API定義的類和接口實現(xiàn)的。 API由兩個程序包組成： 包包含獨立于協(xié)議的類和接口，而 程序包則提供 HTTP 特定的擴展的實用程序類。 Servlet的實質(zhì)是實現(xiàn)了接口 ，實現(xiàn)是直接完成或通過擴展某個支持類來完成的。該接口定義了 Web容器用來管理 servlet和與之交互的方法。用于處理 HTTP 請求的 servlet 一般情況下都會擴展 類。該類實現(xiàn)了 Servlet接口，并提供了使用 HTTP處理的附加方法。 Servlet的生命周期 Web 容器管理 servlet 生命周期的所有方面。它根據(jù)需要創(chuàng)建 servlet 類的實例、將請求傳遞給實例進行處理，最終刪除實例。對于 HttpServlet來說，容器會在 servlet生命周期的適當時間調(diào)用方法。 除了 doGet（）和 doPost（）方法之外，還有一些對應于其他 HTTP方法的方法：doDelete（）、 doHead（）、 doOptiongs（）、 doPut（）和 doTrace（）。一般情況下不用實現(xiàn)這些方法，因為 HttpServlet 類已經(jīng)用適用于大多數(shù) servlet 的方法考慮到了 HEAD、 OPTIONS和 TRACE請求，而且 DELETE和 PUT這兩種 HTTP方法很少用在 Web應用程序中。 容器只為每個 Servlet 創(chuàng)建一個實例非常重要。這意味著 servlet 必須是線程安全的 — 即，能夠同時處理多個請求，每個處理都通過 servlet 代碼作為單獨的線程來執(zhí)行。如果只在 init（）和 destroy（）方法中修改參考的對象，而且只在請求處理方法中讀取他們，那么不用喪失任何細節(jié)就可以滿足關于實例變量的這個要求。 編譯和安裝 servlet 要編譯 servlet，必須首先確保 JAR 文件包含著 CLASSPATH 環(huán)境變量中所有Servlet API類。該 JAR文件將隨所有的 Web容器一起發(fā)布。 Tomcat中包含了一個名為 的 JAR 文件，位于 mon/lib 目錄中。在 Windows 平臺中，應在 16 CLASSPATH中包含 JAR文件。 讀取請求 傳遞到 doGet（）和 doPost（）方法的參數(shù)之一是實現(xiàn)了 HttpServletRequest接口的對象。該接口定義的方法可提供對關于請求的許多信息的訪問。 生成應答 除應答對象之外，容器還將實現(xiàn) HttpServletRequest接口的對象作為 icanshu傳遞給 doGet（）和 doPost（）方法。該接口定義了為應答行為體獲取數(shù)序程序或流的方法。它還定義了設置應答狀態(tài)代碼和首部的方法。 使用過濾器和監(jiān)聽器 Servlet 規(guī)范 servlet 內(nèi)定義了兩種組件類型：過濾器和監(jiān)聽器。這兩種類型是在Servlet ，因此，如果你使用的是不支持該版本規(guī)范的容器，恐怕就不能繼續(xù)學習了 。 過濾器 過濾器是一種組件，可以解釋對 servlet、 JSP頁面或靜態(tài)頁面的請求以及發(fā)送給客戶端之前的應答。這樣可以很容易地將應用于所有請求的任務集中在一起，例如訪問控制、登錄和內(nèi)容的開銷或應用提供的服務等。過濾器對請求與應答的行為體和首部具有完全訪問權限，因此還可以執(zhí)行各種轉(zhuǎn)換。例如，如果 AcceptLanguage請求首部指出客戶端可以處理壓縮的應 答，那么過濾器就可以壓縮應答的行為體。 過濾器可以應用在特定 servlet上，或匹配某種 URL模式的所有請求上，例如以相同的路徑元素開頭或具有相同擴展名的 URL。 監(jiān)聽器 監(jiān)聽器允許應用程序?qū)μ囟ㄊ录龀龌貞?Servlet ，只能處理會話屬性綁定事件（在添加對象或從會話中刪除對象時）。實現(xiàn)監(jiān)聽器的方式是用保存為會話屬性（使用 ()方法）的對象實現(xiàn) HttpSessionBindingListener 接口。隨著 Servlet 規(guī)范的 版本中新接口的引 入，可以為 servlet 環(huán)境和會話生命周 17 期事件以及激活和鈍化事件（容器用來暫時將會話狀態(tài)保存在磁盤上或?qū)捯浦驳搅硪粋€服務器上）創(chuàng)建監(jiān)聽器。使用新的會話屬性事件監(jiān)聽器還可以在一個位置上處理所有會話的屬性綁定事件，而不是在每個會話中防止單獨的監(jiān)聽器對象。 新類型的監(jiān)聽器遵循的是標準 Java 事件模型。換句話說，監(jiān)聽器是實現(xiàn)了一個或多個監(jiān)聽器接口的類。接口定義的是事件相應的方法。當應用程序啟動是，容易會注冊監(jiān)聽器類，然后該容器會在合適的事件調(diào)用那些事件方法 。 使用監(jiān)聽器初始化共享資源 Bean 一般都有需要在使用 之前進行初始化。例如，它們可能需要對數(shù)據(jù)庫或某些其他外部數(shù)據(jù)源的引用，還可能在內(nèi)存中創(chuàng)建一個初始消息緩存，以便即使是第一個請求數(shù)據(jù)也可以提供更快的訪問?？梢栽谛枰蚕碣Y源的 servlet 和 JSP 頁面中包含初始化共享資源的代碼，但是更標準的方法是在一個位置放置所有這些代碼，并在假設資源已經(jīng)初始化和可用的情況下，使應用程序的其他部分可以正常工作。應用程序生命周期監(jiān)聽器是此類資源初始化的絕好工具。此類監(jiān)聽器實現(xiàn)了 接口，當應用程序啟動和關閉時會 由容器調(diào)用該接口的方法 。 為每個任務選擇正確的組件類型 在之前介紹的項目公告牌應用程序是相當復雜的應用程序。頁面的一般都是純粹的控制器和商務邏輯處理，它訪問數(shù)據(jù)庫以對用戶進行身份驗證，而且多數(shù)頁面都需要訪問控制。在現(xiàn)實生活中，它可能會包含更多的頁面，例如，用于訪問共享文檔檔案、事件表的頁面和用于管理的一組頁面等。由于應用程序在不斷地發(fā)展變化，因此可能變得很難作為純 JSP應用程序來維護。例如，很容易忘記在新頁面中包含訪問控制代碼。 很明顯，這種應用程序可以從使用 JSP頁面與組件類型的組合中受益，其中組件類型由 用于 MVC角色的 servlet規(guī)范所定義。下面看一下主要的要求，并了解如何將他們映射到適當?shù)慕M件類型上： ? 數(shù)據(jù)庫訪問應該是抽象的，從而避免料接應用程序中多個部分的特定數(shù)據(jù)模式或數(shù)據(jù)庫引擎：模型角色中的 bean可以用來完成這種認知。 18 ? 數(shù)據(jù)庫訪問 bean 必須在應用程序啟動時可用于所有其他的部分：應用程序生命周期時間監(jiān)聽器是用了該任務的完美的組件類型。 ? 只有通過驗證的用戶才允許使用應用程序：過濾器可以完成訪問控制以滿足該要求。 ? 用 Java代碼進行請求處理效果最佳： servlet作為控制器正符合需要。 ? 必須很容易改 編外觀呈現(xiàn)：這正是 JSP的反光點，也就是作為視圖。 將 servlet、監(jiān)聽器和過濾器混合起來，就將 JSP頁面對復雜邏輯的需求降到了最低。將這些代碼放置到 Java類中后，就可以使用普通的 Java編譯程序和調(diào)試程序來修復潛在的問題。 使用 servlet集中處理請求 將 servlet 作為所有應用程序請求的公共入口時，可以獲得對應用程序頁面流的整體控制。 Servlet可以根據(jù)所請求行為的結果來決定要生成的應答類型，例如，為所有失敗的請求返回公共的錯誤頁面，或者根據(jù)發(fā)出請求的客戶端返回不同的應答等。在某些使用程序類的 幫助下， servlet 還可以提供諸如輸入驗證、 J18N 準備之類的服務，而且通常會鼓勵使用更有效率的方法來請求處理。 當使用 servlet作為控制器時，必須處理下列基本要求： ? 所有處理請求必須傳遞到單獨的控制器 servlet中。 ? Servlet必須能夠區(qū)分請求，以便進行不同類型的處理。 下面是其他一些你可能希望支持的功能，即使并非所有應用程序都要求： ? 擴展應用程序以便以更靈活的方式支持新類型的請求處理。 ? 在不修改代碼的情況下改變應用程序頁面流的機制。 當然，你可以自己開發(fā)滿足這些要求的 servlet，但是已經(jīng) 有開源式 servlet了，他們可以滿足所有這些要求，甚至還有更多的功能。 將應用程序請求映射到 servlet 使用控制器 servlet的第一個要求是所有請求必須都經(jīng)過該 servlet。該要求可以通 19 過多種方式來滿足。如果你以前曾經(jīng)使用過 servlet，那么你可能習慣于用以/myApp/servlet開頭的 URI來調(diào)用 servlet。這是由 Sun公司的 Java Web Server（ JWS）所引入的一個約定， JWS 是在推出標準 API 之前第一個支持 servlet 的產(chǎn)品。今天，大部分 servlet容器都支持這個約定 ，即使 servlet規(guī)范中并沒有正式的定義。