怎样可以把jsp文件加密？象对asp文件加密那样，使源代码变成乱码？
以便保护知识产权。

如果你使用的Weblogic,那么下面这段节选可能对你有用，虽然它的本意是为了提高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部署描述符要做必要的配置变化，使用预编译指令，如下： 


…


precompile
true


…
 

在一个特定的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 编译对生产系统管理造成重大的风险，因此应该在经过慎重的考虑后再使用它。 

程序方式的预编译 

在WLS下最可靠的预编译JSP的方法是使用Java命令行，weblogic.jspc，它位于WLS安装的lib目录之下的weblogic.jar文件中。这个工具允许开发者在发展阶段和在部署前解决编译时间问题的时候编译需要的JSP文件。它也为生产系统提供一个有能力实现JSP预编译的管理员。这种用法的主要好处是： 

●         文件可以被预编译一次然后可以被多次部署。（这不被服务器实例的重复利用所影响）

●         编译时的例外可以被预先解决而不影响部署。

●         类可以通过集群部署。 

使用weblogic.jspc的缺点是需要人工干涉，并且它在开发时并当在JSP文件变得过时的时候必须被重新运行。然而，考虑到前面的两个方法的讨论，我们几乎不能将这种不方便当成该方法的一个缺点，因此推荐它作为最可靠和最灵活的机制来实现JSP预编译。 

执行weblogic.jspc 

为了更有效的使用weblogic.jspc，你必须首先了解它的用法和语法。这篇文章我们将利用WLS6.1 SP2的工具的功能。注意：下面给出的语法和最好的惯例应该应用于WLS 6.1的所有版本以及新的WLS 7.0。 

为了调用命令行JSP编译器（weblogic.jspc），你必须确定下面的内容： 

●         PATH环境变量必须包含你机器上安装的J2SE1.3包的二进制目录（例如，/opt/j2se/1.3.1/sdk/bin 或者c:sunsoftj2se1.3.1sdkbin），以获得JVM运行时的支持。如果你打算使用javac作为你的JSP编译的Java编译器，要确定PATH包含全部Java 1.3 的软件开发工具包（SDK）的二进制目录，并且不仅仅是JRE（Java Runtime Engine，Java运行时间引擎），因为没有编译器和JRE关联。 如果你打算使用一个编译器而不是javac（例如 Jikes），也要为那个编译器确定在PATH中包含正确的目录。

●         设置Java系统类路径用来包含来自WLS 6.1 SP2 安装目录的weblogic.jar文件，通过在产品库目录下默认建立（例如，/opt/bea/wlserver6.1/lib/weblogic.jar或者c:beawlserv  -er6.1libweblogic.jar）。此外，请确定在JSP编译阶段中你可能需要的参考类（JAR或类文件）也在你的类路径中。

在第一次执行weblogic.jspc之前，你需要测试你的命令行配置是否是按上述配置。它可以通过简单运行一个WLS版本检查来完成，使用命令“java weblogic.version”，这个命令应该返回下面的内容： 

which should return the following:
WebLogic Server 6.1 SP2 12/18/2001 11:13:46
#154529
WebLogic XML Module 6.1 SP2 12/18/2001
11:28:02 #154529 

如果你的输出和上面的不相似（和你运行的版本相对应），在进行JSP预编译前，要重新访问PATH和类路径变量将其设置成你的当前命令行环境。

一般的weblogic.jspc的语法如下面给出的： 

java weblogic.jspc [options] ... 

在一个编译器的单一调用中默认情况下JSP编译器可以编译一个JSP文件或一组JSP文件，并且可以通过设置命令行选项，编译器可以以不同的方法工作。下面给出一个例子： 

java
weblogic.jspc
-webapp mywebapp
-compiler javac
-compileFlags "-g"
-classpath /u/apps/dist/src/lib.jar
-d .
-package com.slackwerks.mywebapp.jsp
-commentary
-keepgenerated
-k
mywebappindex.jsp 

这篇文章只列举了一个例子，如果你要想更加了解weblogic.jspc如何能在你的环境中使用和管理的话，请参阅www.slackwerks.com/wldj，我们提供了对整套的工作选项，使用的含义以及相关联问题的讨论。 

结论

虽然关于JSP预编译的问题较多，但许多的途径可以解决。然而，考虑到上文所说的那些优点和缺点，应该较容易的看出经由weblogic.jspc预编译的程序方式是为克服JSP固有的缺点的一个灵活的选项。在开发阶段的早期，熟悉该工具将改善生产期间应用程序的管理和性能状况。 

所有的得请求用servlet处理，把jsp放在WEB-INF目录下，用户就无法访问了。
只有通过servlet处理后才将jsp返回给用户。

至于classload加密过程，再此处不适用。