简介：将标记库存放在本地文件系统中的确有利于内部（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