IBM WebSphere 开发者技术期刊: WebSphere Application Server Technology for Developers V6 中的 JavaServer Page - 第 1 部分

文档选项 未显示需要 JavaScript 的文档选项 样例代码

级别： 初级

Scott Johnson (scottjoh@us.ibm.com), IBM WebSphere Application Server Development, IBM

2004 年 2 月 01 日

本文是一个分为三部分的系列文章的第一篇，它描述批处理编译器的一些内部操作，并探讨了 WebSphere Application Server Technology for Developers V6.0 中提供的批处理编译器配置参数。另外两部分也将焦点放在 WebSphere Application Server V6.0 TD 上，其中第 2 部分将讨论 JSP Engine 的性能调优，而第 3 部分将探讨 JavaServer Pages Engine 的体系结构。

简介

JavaServer Pages (JSP) 可以在 Web 应用程序开发之际、应用程序部署之前进行编译。在一个预先部署的应用程序中对 JSP 进行批处理编译，可以简化部署过程。由于消除了第一次请求（first-request）编译，因而又提高了 JSP 的运行时性能。批处理编译器还可以对那些已部署到 IBM WebSphere Application Server 中的企业应用程序进行操作。

本文将描述批处理编译器的一些内部操作，并且还将探讨 WebSphere Application Server Version 6.0 TD 中可用的所有批处理编译器配置参数。本系列文章的第 2 部分和第 3 部分将分别讨论 WebSphere Application Server Technology for Developers V6.0 TD 中 JSP Engine 的性能调优和探讨 JavaServer Pages Engine 的体系结构。

回页首

批处理编译器操作

批处理编译器验证 JSP 的语法，将 JSP 翻译成 Java 源文件，并把 Java 源文件编译成 Java Servlet 类文件。同样，它还验证 Tag 文件并生成它们的 Java 实现类。

批处理编译器有很多配置参数，这使得应用程序开发人员或部署人员能够控制其行为（请参阅 批处理编译器配置参数）。虽然配置批处理编译器的方式有很多种，但是只有一个必需的配置参数：批处理编译器 target。该配置参数的缺省值在大多数情况下都很合适，这也使得这种工具易于使用。

受支持的 JSP 和 servlet 规范

批处理编译器可以对支持 Servlet 2.4 规范（或者 Servlet 2.2 这样的早期规范）的 Web 模块进行操作。它可以对按照 JSP 2.0 规范（或者 JSP 1.0 这样的早期规范）编写的 JSP 进行操作。批处理编译器能够识别 Servlet 2.4 (JSP 2.0) 部署描述符（web.xml），并且可以使用它所能包含的任何 jsp-config 元素。在 Servlet 2.3 (JSP 1.2) 或 Servlet 2.2 (JSP 1.1) 部署描述符中，批处理编译器可以识别和使用该描述符可能包含的任何 taglib 元素。

批处理编译器目标

可以对压缩的或展开的企业应用程序归档（Enterprise Application Archives，EAR）和 Web 应用程序归档（Web Application Archives，WAR），以及已经部署到 WebSphere Application Server 中的企业应用程序和 Web 模块执行批处理编译器。如果目标是一个已部署的企业应用程序，无需运行服务器就可以执行批处理编译器。如果在目标服务器正在运行时执行批处理编译器，那么除非重新启动企业应用程序，否则服务器将不知道经过更新的类文件，也不会装载那个类文件。如果目标是一个压缩的 EAR 或 WAR，批处理编译器就必须首先扩展它，然后再执行。 表 3描述了批处理编译器展开 EAR 和 WAR 的情景。

对 Web 模块的处理

批处理编译器一次只对一个 Web 模块进行操作。如果目标是一个 EAR，或者是一个已安装的、包含不止一个 Web 模块的企业应用程序，那么批处理编译器就会逐个地对每个 Web 模块进行操作。这是因为 JSP 是按照 Web 模块并通过 Web 模块的 web.xml 部署描述符来配置的。

在一个 Web 模块内，批处理编译器一次处理一个目录。它逐个地验证和翻译每个 JSP，然后为那个目录中生成的整组 Java 源文件调用 Java 编译器。如果在 Java 编译阶段有一个 JSP 文件编译失败，则 Java 编译器可能不会为那个目录中成功通过编译的大部分或所有 JSP 创建类文件。

JSP 文件扩展名

批处理编译器通过 4 种情况来判断它该处理什么样的文件扩展名：

1. 标准 JSP 文件扩展名
   • *.jsp
   • *.jspx
   • *.jsw
   • *.jsv
2. Servlet 2.4 Web 模块内部署描述符中 jsp-property-group 元素的 url-pattern 属性。
3. jsp.file.extensions JSP Engine 配置参数（用于 pre-Servlet 2.4 Web 模块）。
4. 批处理编译器 配置参数 jsp.file.extensions。

批处理编译器总是使用标准扩展名。如果 Web 模块包含 Servlet 2.4 部署描述符，则批处理编译器还将处理 jsp-config 元素中出现的任何 url-pattern。如果批处理编译器目标包含 JSP Engine 配置参数 jsp.file.extensions，则那些扩展名也将得到处理。如果提供了批处理编译器配置参数 jsp.file.extensions，那么批处理编译器还将处理这里给出的扩展名，并重写 JSP Engine 配置参数 jsp.file.extensions。

为 JSP “片段（fragment）”提供一个批处理编译器不进行处理的扩展名，这是一个很好的方法。对于那些将来不会单独使用的静态包含的（Statically-included）片段，处理它们时将会生成翻译或编译错误。对于这一类的文件，JSP 2.0 规范建议使用扩展名 .jspf 。

JSP Engine 配置参数

批处理编译器有 9 个配置参数，在 WebSphere Application Server JSP Engine 中可以找到与它们等效的参数。如果给出了 JSP Engine 参数，那么在等效的批处理编译器参数没有给出的时候，这些 JSP Engine 参数就充当缺省参数。（请参阅 三组配置参数以及它们的优先级）。这些参数是：

表 1. 批处理编译器参数和等效的 JSP Engine 参数

批处理编译器不会创建 JSP Engine 参数，或者设置这些参数的值。这意味着如果对一个已部署的 Web 模块中的某个 JSP 作了修改，并且在运行时由 JSP Engine 对其重新编译，则 JSP Engine 的配置参数将决定引擎的行为。如果在已部署的 Web 模块中预先编译好的 JSP 永不会修改，那么这就无关紧要了。如果在已部署的 Web 模块中对它们作了修改，那么引擎的参数应该设置为批处理编译时用到的同一值。

判断何时需要编译 JSP

如果 JSP 的类文件的时间戳不同于 -- 迟于或早于 -- JSP 的时间戳，那么就认为该类文件已过期。如果类文件已过期，或者类文件不存在，批处理编译器将翻译和编译 JSP。（即使 JSP 的类文件已过期，还是可以用 JSP Engine 配置参数来禁用 JSP 的运行时编译。请参阅 JSP Engine 性能考虑。）

一个 JSP 可能存在某些附属文件（请参阅 trackDependencies）。如果 trackDependencies 配置参数被设置为 true，并且在最近一次翻译和编译了一个 JSP 之后修改了该 JSP 任意一个附属文件的时间戳，那么就会重新生成一个 JSP 类文件。JSP 的附属文件的名称和时间戳存储在类文件中，这样批处理编译器（以及在运行时的 JSP Engine）就可以判断是否有附属文件曾被修改。

通过使用参数 forceCompilation，可以强制用批处理编译器对 JSP 进行编译 -- 不管类文件是否过期，也不管是否有附属文件被修改（请参阅 可选的配置参数）。

决定在哪里生成类文件

在运行时，WebSphere Application Server JSP Engine 将从 WebSphere Application Server 临时目录或者 Web 模块的 WEB-INF/classes 目录装载 JSP 类文件。WebSphere Application Server 临时目录通常是 {WAS_ROOT}/temp 。WebSphere Application Server JSP Engine 首先在临时目录中搜索类文件，如果没有搜索到，便再到 Web 模块的 WEB-INF/classes 目录中去搜索。图 1 显示了 JSP Engine 在运行时的处理逻辑。

批处理编译器同时支持在 WebSphere Application Server 临时目录和在 Web 模块的 WEB-INF/classes 目录中生成类文件，具体在哪个目录中要取决于批处理编译器目标的类型。此外，批处理编译器还支持将类文件生成到文件系统上目标应用程序以外的任何目录中。请参阅 表 4以了解详情。

将类文件生成到一个 Web 模块的 WEB-INF/classes 目录中，这样可以将此 Web 模块部署为一个自包含 WAR 或者一个 EAR 内的 WAR。

批处理编译器类路径

批处理编译器像表 2 所示的那样建立其类路径。当批处理编译器目标是一个 WAR 时（提供 war.path ），可以用配置参数 additional.classpath 来给出额外的类路径信息。

表 2. 批处理编译器类路径

记录

批处理编译器会将其操作记录到控制台和一个日志文件 {WAS_ROOT}/logs/jspBatchCompilerTrace.log 。缺省的记录级别是 CONFIG，在此级别将记录处理信息和任何异常，或者碰到的 JSP 翻译或编译错误。如果为了便于调试，需要更细的记录级别，那么可以使用 log.level 参数（请参阅 log.level）。

JSP Engine 性能考虑

JSP Engine 提供了一个配置参数 disableJspRuntimeCompilation，该参数可以禁用 JSP 的运行时编译。对于该引擎来说，这是最有效的一种模式，因为它再也不用检查类文件是否过期，从而避免了所有的文件系统检查。这种设置要求提供 JSP 的类文件，即使是第一次请求亦需如此。要想使用这个参数，在部署应用程序时，所有的 JSP 类文件都必须存在。在应用程序装配的最后阶段，可以使用批处理编译器参数 forceCompilation 来确保在部署之前所有的 JSP 类文件都已存在。

如果在运行时修改了 JSP，需要重新装载这些 JSP 以便使修改生效，那么可以使用 JSP Engine 参数 reloadEnabled 和 reloadInterval。reloadEnabled 参数决定了如果 JSP 文件或者其附属文件（请参阅 trackDependencies）被修改，是否要在运行时重新翻译和重新编译该 JSP 文件。注意，如果 reloadEnabled 为 false（缺省值），除非 disableJspRuntimeCompilation 属性为 true，否则在 JSP 第一次被请求时，仍然要编译该 JSP。如果允许重新装载，则 reloadInterval 将决定从 JSP 被请求，到引擎开始检查重新装载是否有必要，这之间引擎要等待多少秒钟的时间。

JSP Engine 还提供了一个开发模式（development-mode）参数 trackDependencies。如果在部署期间服务器正被使用，那么当一个 JSP 的附属文件遭到更改时，重新编译该 JSP 是有益的。对于引擎来说，这是一种低效率的模式，因为这种模式要求文件系统对于每次请求都要检查 JSP。如果您想使用这个引擎参数，那么在将应用程序部署到 WebSphere Application Server 之前，应确保使用等效的批处理编译器参数 -- 批处理编译器将生成所有必需的附属文件跟踪信息，之后，引擎将在运行时使用这些信息。如果参数 trackDependencies 被设置为 true，那么除非是因为某个 JSP 遭到更改，或者其类文件已被删除，而重新编译了该 JSP，否则引擎不会自动地生成这种信息。

JSP Engine 参数 useThreadTagPool 和 usePageTagPool 可以使那些大量使用自定义标记的 JSP 提高性能。在进行批处理编译时，应确保将所需的等效批处理编译器参数设置为 true，以便 JSP Engine 能够在运行时使用池（pooling）。

回页首

批处理编译器命令

不管是 Windows 批处理文件（ JspBatchCompiler.bat ），还是 UNIX shell script （ JspBatchCompiler.sh ），这两个用来从命令行运行批处理编译器的文件都可以在 {WAS_ROOT}/bin 中找到。为了使用 Ant 执行批处理编译器，这里还提供了一个 Ant 任务（请参阅 批处理编译器 Ant 任务）。

批处理编译器命令看上去是这样的：

JspBatchCompiler
 -ear.path <path> | -war.path <path> | -enterpriseapp.name <name>
 [-response.file <filename>]
 [-webmodule.name <name>]
 [-filename <jsp name | directory name>]
 [-config.root <path>]
 [-cell.name <name>]
 [-node.name <name>]
 [-server.name <name>]
 [-extractToDir <path>]
 [-compileToDir <path>]
 [-compileToWebInf <true|false>]
 [-forceCompilation <true|false>]
 [-trackDependencies <true|false>]
 [-createDebugClassfiles <true|false>]
 [-keepgenerated <true|false>]
 [-keepGeneratedclassfiles <true|false>]
 [-usePageTagPool <true|false>]
 [-useThreadTagPool <true|false>]
 [-classloader.parentFirst <true|false>]
 [-classloader.singleWarClassloader <true|false>]
 [-additional.classpath <classpath>]
 [-verbose <true|false>]
 [-deprecation <true|false>]
 [-compileWithAssert <true|false>]
 [-useJikes <true|false>]
 [-jsp.file.extensions <file extensions to process>]
 [-log.level <SEVERE | WARNING | INFO | CONFIG | FINE | FINER | FINEST | OFF>]
                

下面是从 Windows 命令提示符输入的一个示例批处理编译器命令：

C:\WAS\AppServer\bin>jspbatchcompiler -enterpriseapp.name sampleApp -forcecompilation true -verbose true

回页首

批处理编译器配置参数

• 批处理编译器配置参数不是大小写敏感的。例如：
  
  -usePageTagPool 与 -usepagetagpool 是一样的。
  
  
• 每个参数后面都必须跟上它的值，参数和值之间由一个或多个空格隔开。例如：
  
  -enterpriseapp.name myWebApplication
  
  
• 在命令行和响应文件中，参数可以以任何顺序出现。在下面的 可选的配置参数中我们描述了 response.file 参数。

三组配置参数以及它们的优先级

批处理编译器理解三组配置参数：

1. 用于 Web 模块的 JSP Engine 配置参数。
   这些参数是为特定 Web 模块的 JSP 支持而设置的，通常用于已部署的应用程序中。例如，对于很多版本的 WebSphere Application Server，都可以使用 keepgenerated 这个参数来控制由 JSP Engine 生成的 JSP 源文件的保存以及删除。
   • JSP Engine 配置参数存储在 Web 模块的配置目录下的 WEB-INF/ibm-web-ext.xmi 文件中。配置目录的一个例子是：
     
     {WAS_ROOT}/config/cells/cellname/applications/enterpriseappname/deployments/deployedname/webmodulename
     
     
   • 如果应用程序是在将标志 "Use Binary Configuration" 设为 true 的情况下部署到 WebSphere Application Server 中的，那么就应该在 Web 模块的二进制目录，而不是配置目录中寻找 WEB-INF/ibm-web-ext.xmi 文件。二进制目录的一个例子是：
     
     {WAS_ROOT}/installedApps/nodename/EnterpriseAppName/WebModuleName/
     
     
   • ibm-web-ext.xmi 中对应于 JSP Engine 配置参数的条目看上去类似于以下例子：
     
     <jspAttributes xmi:id="JSPAttribute_6" name="keepgenerated" value="true"/>
     
     
2. 响应文件配置参数。
   这些参数可以在一个批处理编译器响应文件中找到。
3. 批处理编译器命令行配置参数。
   这些是在运行批处理编译器时在命令行输入的参数。

批处理编译器检查所有这三组配置参数，以决定在编译 JSP 时采用参数的哪个值。在决定一个给定参数的值时，优先级是这样的：

1. 如果该参数出现在命令行，则直接使用它的值。如果该参数不在命令行，则批处理编译器查找
2. 命令行指定的响应文件中的参数。如果没有指定响应文件，或者在响应文件中没有找到该参数，则批处理编译器检查
3. Web 模块的 JSP Engine 配置参数中的参数。（请参阅 JSP Engine 配置参数。）

如果在这三组参数中都没有找到那个配置参数，那么就使用一个缺省值。在下面的 所需的配置参数和 可选的配置参数这两节中，给出了各配置参数的缺省值，以及对这些参数的描述。

所需的配置参数: 批处理编译器目标

在 ear.path、war.path 和 enterpriseapp.name 这三个参数中，有且只有一个参数是必需的。这些参数不一定要在命令行中给出。相反，它们也可以出现在响应文件中。

ear.path

war.path

enterpriseapp.name

可选的配置参数

response.file

webmodule.name

filename

config.root

cell.name

node.name

server.name

extractToDir

compileToDir

compileToWebInf

forceCompilation

trackDependencies

log.level

回页首

批处理编译器 ant 任务

ant 任务 JspC 公开所有批处理编译器配置选项。该任务在幕后执行批处理编译器。它与 WebSphere Application Server 5.x 版本的 JspC ant 任务向后兼容。表 5 列出了所有 ant 任务属性以及与它们等效的批处理编译器参数。在清单 1 中展示了一个实例 build.xml。在 下载文件中提供了 JspC 的 Javadoc。


表 5. JspC ant 任务属性以及与它们等效的批处理编译器参数

<project name="jsp" default="jspc_test" basedir=".">
<taskdef name="wsjspc" classname="com.ibm.websphere.ant.tasks.JspC"/>
 <target name="jspc_test" description="example usage of JspC task">
  <wsjspc wasHome="C:\WAS\AppSer"
  earpath="C:\WAS\AppSer\installedApps\sdjt30\myApp.ear"  webmodulename="examples.war"
  forcecompilation="true"
  verbose="false"
  deprecation="false"
  loglevel="CONFIG"
  />
 </target>
</project> 
                

回页首

结束语

WebSphere Application Server 批处理编译器是一种高度可配置的工具，它支持对压缩和展开的 EAR 及 WAR 中的 JSP，以及已部署到 WebSphere Application Server 上企业应用程序中的 JSP 进行编译。批处理编译器可以帮助简化应用程序的部署，因为它支持将 JSP 预先编译后直接放入 Web 模块。批处理编译器知道所有的 JSP Engine 运行时配置属性，这样就可以直接生成在运行时引擎中可以使用的 JSP 类文件，而不必预先编译。在应用程序部署期间，批处理编译器是一种方便的工具，可用于验证所有 JSP 文件以及它们所包括的文件是否合法，以及验证它们所依赖的所有类和 JAR 是否可见。

回页首

致谢

作者想要感谢 Todd Kaplinger 和 Richard Backhouse 对本文所作出的贡献。

回页首

下载

	关于下载方法的信息

关于作者

		Scott Johnson是 WebSphere Application Server JSP Engine 的小组负责人。他于 2000 年加入 IBM，在 Research Triangle Park Lab 工作，在此之前的 17 年他曾担任程序员和项目负责人。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首