簡介：將標記庫存放在本地文件系統中的確有利於內部（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
