欢迎来到“管理角”这个版，新一期的月刊专栏专注于 WebLogic 服务器的管理、配置、处理和开发方面。
开辟这个专栏的目的是为了向大家介绍在使用WebLogic Sever时，能普遍用到的非J2EE开发方面的问题。开发者和管理者同样会发现这个专栏非常有价值，因为这些文章既适用于开发又适用于最终产品的应用。此外，它很大程度上利用了来自于该领域和工程实验室的经验，它提供了对实际问题的详细解答。
JSP预编译的必要性
本文着眼于移除潜在的系统性能瓶颈，它通过解决一个最普通的问题??在服务器运行时间中的JSP (JavaServer Page)编译的系统开销问题，这个问题困扰着几乎所有的J2EE发展计划。虽然JSP是在J2EE应用范围内呈现动态HTML视图的理想选择，但在某种程度上它们会影响性能，这比错误的更令人讨厌，给人的第一感觉是该程序很慢。
根据J2EE规范，JSP主要是HTML文件，在它里面包含着Java代码用来和其他的系统组件进行交互以及动态的显示信息。规范规定所有的J2EE编译应用服务器应当支持JSP，客户请求一个特定的JSP，将：
● 转换JSP从HTML格式成为servlet类型的Java类（Java源格式），用简写的JSP符号代替完全符合规定的Java语法
● 将新产生的Java源文件编译成.class字节码形式
● 在新编译的类上执行适当的接口方法并且对客户端请求返回响应。
虽然从发展的观点来看对于在表示层内管理动态HTML的产生这是最好的途径，但它影响到服务器的运行时间环境，要求JSP被解析、转变成Java代码，并且在它去处理一个特定的客户端请求之前被编译。对最终用户明显的影响是，一个响应将会被延迟知道给定的JSP文件被编译通过。考虑到一个特定的用户请求可能用到两个或多个JSP文件，因此编译状态必需的时间增加了很多倍。
对第一个请求一个特定的JSP页面并且迫使被请求的文件进行初始编译的终端用户，会感觉应用程序很慢并且没有响应。 虽然这样的感觉可能存在，但是对于特定的JSP文件的编译过程通常在给定的应用服务器虚拟机实例的生命周期中完成一次。 因此，它对性能总体上的影响被考虑成一种障碍，而不是对应用程序总响应时间的一个严重的障碍。然而，在生产环境中为了传送基于JSP的J2EE应用程序的生产系统，必须克服JSP的缺陷并且对最终用户进行透明的编译。
这样，生产环境如何能受益于JSP文件，还要避免运行时编译的性能打击？答案是简单的：执行一个一般作为JSP预编译的过程。 借用JSP预编译，已经被预编译的在脱机环境中的JSP文件和他们的编译结果被部署在生产环境中。如果结果类文件的预编译和部署正确的完成，应用程序服务器将会为JSP文件运行先前的编译类，并且在运行中将不强制对特定的请求进行再编译。 这样产生了一种情况，应用程序的操作避免了多余的编译开销，允许系统管理员移除对系统总性能会造成影响的一个已知的瓶颈。
不同的方法论和途径
没有人怀疑JSP预编译的承诺听起来令人兴奋。 然而，为了要实现这样的承诺，你必须首先了解能够执行这个技术的不同途径，以及它们各自优点和缺点。
运行应用程序进行强制预编译
用于实现JSP预编译最显而易见的方法是在产品发布前，通过请求在应用程序中的所有可能的JSP页面，因此编译在终端用户访问站点前完成。它既可以通过第一次人工浏览整个站点时完成也可以通过从测试系列应用程序或其他脚本语言的客户端（例如LoadRunner 或 SilkPerformer）发动自动请求来实现。 当使用这种方法（可能是所有的JSP预编译方法中的最简单的而又较下策的一个方法）时，他的缺点很快就显现出来了。也许最大的缺点是很难实现跨集群环境，在集群环境中，用该方法对于单一节点的实例发送的请求依集群中的节点数量成倍的增加。而且，当这个集群是由一个或更多的Web服务器或硬件负载权衡者来代理时，更难保证在一个集群的环境中每个服务器实例都进行JSP预编译，因为一般没有方法来搞清代理最初把请求转到哪个应用服务器。此外，在应用服务器每次重启时，这个方法必须执行，当站点很小时，不能一次实现所有的编译就会很痛苦。因此，我们不推荐这种JSP预编译的方法。
使用编译工具来实现预编译
因为人工执行一个站点应用程序来强制JSP预编译在真实的产品环境中是一个较大的缺点，在预编译运行期间选择编译JSP，使其变成为servlets变得更令人心动。幸运地，WLS提供了二个方法。第一种方法在服务器启动部署一个特定的Web应用程序的时候执行预编译（declarative预编译），第二种方法是命令行Java工具（weblogic.jspc）允许过程在完全脱机的情况下处理（程序方式的预编译）。两种方法都有它们的优点，程序方式的预编译在两者中有更灵活的选项，并且提供更让人无法抗拒的理由来使用它。
DECLARATIVE预编译
对于在WLS下公布的预编译，一个特定的Web应用程序（独立的或者作为EAR的一部分）能够被配置，因此所有的JSP在应用程序部署（服务器启动时）和重新部署（运行时）期间里被预编译。对WEB-INF/ weblogic.xml部署描述符要做必要的配置变化，使用预编译指令，如下：
<weblogic-web-app>
…
<jsp-descriptor>
<jsp-param>
<param-name>precompile</param-name>
<param-value>true</param-value>
</jsp-param>
</jsp-descriptor>
…
</weblogic-web-app>
在一个特定的Web应用程序上进行部署（或重新部署），如果上述的参数被设定成真， WLS 将会在WAR内尝试预编译所有的JSP文件，在程序中从 Web 应用程序的根目录下循环的运行它的方法( 略过Web-INF) 。以. jsp 或 .JSP为扩展名的文件都变成了编译的对象。 被编译后的文件被以适当的包目录结构形式被放置在Web 应用程序的临时工作目录下面（默认在Web-INF子目录中，除非在 weblogic.xml 里有特别说明）。
这个方法是到目前为止进行JSP预编译最方便的途径（“flick-a-switch” 途径），他有许多指出来毫无意义的缺点。如果一个错误在JSP的编译期间或在部署(或重新部署) 的时候发生，Web 应用程序的预编译将会在例外处暂停。另外，如果在一个特定的Web应用程序里面有许多JSP文件的情况，declarative预编译显著的影响着部署时间，阻断部署直到所有的文件都被编译。对于大型的应用程序，当出现数以百计的JSP 文件以declarative预编译被执行的时候，这种部署时间趋向以分钟来计算 (在某些情况10到15分钟，其他情况可能更长时间)。设想开始一个服务器实例，在一个特定的Web应用程序周期内进入部署状态用declarative 预编译激活。如果在应用内有很多的JSP文件以及部署，接近完成时就已经花费了大量的时间，在编译期间由于抛出一个例外而突然失败，当然会引起挫折感。虽然起先看起来比较方便，但declarative 编译对生产系统管理造成重大的风险，因此应该在经过慎重的考虑后再使用它。
