JSP最佳實務: 將自訂標籤庫打包

簡介：將標記庫存放在本地檔案系統中的確有利於內部（in-house）開發與測試，但是這並非永遠都 是好的解決方案。自訂標籤庫應該能夠被廣泛地訪問，也就是說，必須以一種標準的和安全的方式來發 布它們。BrettMcLaughlin 解釋了如何將您的自訂標籤庫打包到 JAR 檔案，以便在任何 JSP 相容的 Web 容器中更容易地維護、發布和安裝它們。

到目前為止，我們在本系列中講到的都是自訂標籤庫在本地檔案系統中的情況，在這種情況下，我 們可以很容易地訪問和操作這些自訂標籤庫。然而，雖然本地訪問對於內部（in-house）開發和設計來 說很有用，但這並非永遠都是一個好的解決方案。自訂標籤庫的最終目的就是它們應該能夠被廣泛地訪 問，這意味著必須以一種標準化的方式來發布自訂標籤庫，並且這種方式允許一些必要的安全措施。在 本期的 JSP 最佳實務中，您將學習如何將自訂標籤庫打包到一個 JAR 檔案中，以便更安全和更容易地 發布。

為什麼使用 JAR?

自訂標籤庫本身就是要被發布的，既可能是在公司開發小組這麼一個小圈子內發布，或者是在聯合 組織這樣更大的圈子內發布，也可能是在面向付費客戶的外部網路上發布。但不管是哪種情況，將標記庫 存放在本地檔案系統中並使其在該位置可用，都不是一個好主意。

如果您的標記庫是用於一個內部（in-house）開發小組，那麼在發布該標記庫時您首先想到的就是要 分清責任。在 JSP 編程中，理想的情況是擁有兩個並行工作的開發小組：Java 開發人員負責編寫實現細 節，而 JSP 頁面設計者則負責處理前端。但是經驗表明，如果不強制執行的話，這種分工很快就打破了 。將自訂標籤庫放在一個可以從本地訪問的檔案系統中這種做法會造成一種不利的情形，在這種情形下 ，即使是好意的行為 -- 例如 JSP 頁面設計者“改正” TLD 檔案，或者 Java 程式員“調整” HTML -- 也可能給開發週期以及最終產品帶來破壞。

如果將遠程方（例如外部公司或組織）這一因素也考慮進來，那麼這種情形就更加嚴重了。無論何時 您允許不受控制的外方（例如終端使用者或者頁面設計者）訪問您的代碼，都將招致麻煩。例如，假設一個 外部公司的使用者更改您的 TLD，或者搞亂標記類檔案。這樣一來，您不但要因為產生的錯誤而受到責備， 而且很可能找不出到底是誰犯下這樣的錯誤。您將花費雙倍的時間來調試代碼，而實際上問題的起因不過 是一個使用者錯誤。這種類型的錯誤往往不止出現一次 -- 只要您將主標記庫存放在一個可以從本地訪問的 檔案系統中，這種錯誤就會重複出現。

最後，讓我們考慮一下，如果您決定將自訂標籤庫推向市場進行出售，會出現什麼情況呢？現今， 對類進行反編譯十分容易，這就意味著某些人可以輕易地買到您的代碼，加以修改，然後惡意地以您公司 的名義使用它。或者，他們可以簡單地重新打包它，將其放在他們自己的網站上出售。不管是哪種情形， 對於您來說都不是什麼好事。將代碼打亂（這使得反編譯二進位代碼變得很難，而且通常是不可能的）是 避免惡意修改或者剽竊的好方法。將您的標記庫打包到一個單獨的、離散的單元中也是推薦的做法。

JSP 規範允許我們使用 Java 平台的 JAR 工具打包自訂標籤庫。一旦這些自訂標籤庫被打包到 JAR 檔案中，就可以廣泛地發布、維護和安裝。而且，您將看到，將標記庫打包到 JAR 檔案中並不很難 。

建立標記庫目錄

第一步就是像清單 1 顯示的那樣建立一個標記庫目錄結構：

清單 1. 用於標記庫 JAR 的目錄結構

$basedir/
　　　　　 META-INF/
　　　　 META-INF/site-utils.tld
　　　　 com/
　　　　 com/newInstance/
　　　　 com/newInstance/site/
　　　　 com/newInstance/site/tags/
　　　　 com/newInstance/site/tags/LastModifiedTag.class
　　　　 com/newInstance/site/tags/SSOSubmitTag.class
　　　　 com/newInstance/site/tags/CopyrightTag.class
　　　　 com/newInstance/site/utils/HTMLParser.class
　　　　 com/newInstance/site/utils/RegExp.class