规范规定所有的J2EE编译应用服务器应当支持JSP，客户请求一个特定的JSP，将：

　　转换JSP从HTML格式成为servlet类型的Java类(Java源格式)，用简写的JSP符号代替完全符合规定的Java语法

　　将新产生的Java源文件编译成.class字节码形式

　　在新编译的类上执行适当的接口方法并且对客户端请求返回响应。

　　虽然从发展的观点来看对于在表示层内管理动态HTML的产生这是最好的途径，但它影响到服务器的运行时间环境，要求JSP被解析、转变成Java代码，并且在它去处理一个特定的客户端请求之前被编译。对最终用户明显的影响是，一个响应将会被延迟知道给定的JSP文件被编译通过。考虑到一个特定的用户请求可能用到两个或多个JSP文件，因此编译状态必需的时间增加了很多倍。

　　jsp的预编译一般有以下几种方式

　　1.运行应用程序进行强制预编译

　　用于实现JSP预编译最显而易见的方法是在产品发布前，通过请求在应用程序中的所有可能的JSP页面，因此编译在终端用户访问站点前完成。它既可以通过第一次人工浏览整个站点时完成也可以通过从测试系列应用程序或其他脚本语言的客户端(例如LoadRunner 或 SilkPerformer)发动自动请求来实现。

　　2.使用编译工具来实现预编译

　　因为人工执行一个站点应用程序来强制JSP预编译在真实的产品环境中是一个较大的缺点，在预编译运行期间选择编译JSP，使其变成为servlets变得更令人心动。幸运地，WLS提供了二个方法。第一种方法在服务器启动部署一个特定的Web应用程序的时候执行预编译(declarative预编译)，第二种方法是命令行Java工具(weblogic.jspc)允许过程在完全脱机的情况下处理(程序方式的预编译)。两种方法都有它们的优点，程序方式的预编译在两者中有更灵活的选项，并且提供更让人无法抗拒的理由来使用它。

　　3.DECLARATIVE预编译

　　对WEB-INF/ weblogic.xml部署描述符要做必要的配置变化，使用预编译< jsp-param/>指令，如下：

　　< 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为扩展名的文件都变成了编译的对象。这个方法是到目前为止进行JSP预编译最方便的途径(“flick-a-switch” 途径)，他有许多指出来毫无意义的缺点。如果一个错误在JSP的编译期间或在部署(或重新部署) 的时候发生，Web 应用程序的预编译将会在例外处暂停。