Web 容器

5004315 

在 Windows 上，使用 --precompilejsp=true 部署应用程序时，会锁定该应用程序中的 JAR，从而导致以后无法取消部署或重新部署。

如果您在 Windows 上部署应用程序时要求预编译 JSP，则以后尝试取消部署该应用程序或重新部署该应用程序（或任何具有相同模块 ID 的应用程序）的操作将不会按预期进行。出现此问题的原因是：JSP 预编译会打开应用程序中的 JAR 文件，但不能关闭这些文件，Windows 将禁止执行取消部署或重新部署操作以避免删除或覆盖它们。 

请注意，取消部署在某种程度上是成功的，因为应用程序会从 Application Server 中被逻辑删除。另外请注意，asadmin 实用程序不会返回任何错误消息，但应用程序的目录以及锁定的 jar 文件会保留在服务器中。服务器的日志文件将包含用于说明未能删除文件和应用程序的目录的消息。

在取消部署后尝试重新部署应用程序的操作会失败，这是由于服务器尝试删除现有文件和目录，而这些尝试也失败了。如果您尝试部署的应用程序所使用的模块 ID 与最初部署的应用程序的模块 ID 相同，会出现这种情况，这是由于服务器在选择目录名来保存应用程序的文件时会使用模块 ID。 

如果没有先取消部署应用程序而尝试重新部署该应用程序，也将会由于同样的原因而失败。 

诊断

如果尝试重新部署应用程序或在取消部署后部署它，asadmin 实用程序将返回一个类似如下的错误。 

An exception occurred while running the command. The exception message is: 
CLI171 Command deploy failed : Deploying application in domain failed; 
Cannot deploy. Module directory is locked and can't be deleted.

解决方法

如果在部署应用程序时指定 --precompilejsps=false（默认设置），则不会出现此问题。请注意，第一次使用应用程序时会触发 JSP 编译，因此第一个请求的响应时间将会长于随后的请求的响应时间。

另外，请注意，如果您确实进行了预编译，则在取消部署或重新部署应用程序之前，应先停止并重新启动服务器。关闭服务器后将释放锁定的 JAR 文件，这样在重新启动服务器后，取消部署或重新部署便可以成功。 

6172006 

无法使用基于 Servlet 2.4 且包含空 <load-on-startup> 元素的 web.xml 来部署 WAR。

web.xml 中的可选 load-on-startup servlet 元素表示相关的 servlet 将在启动对其进行声明的 Web 应用程序期间被加载和初始化。

此元素的可选内容是一个整数，用于表示该 servlet 相对于 Web 应用程序的其他 servlet 而被装入和初始化的顺序。只要该 servlet 在包含它的 Web 应用程序启动期间被加载和初始化，空的 <load-on-startup> 就表示顺序无关紧要。

web.xml 的 Servlet 2.4 模式不再支持空的 <load-on-startup>，这意味着在使用基于 Servlet 2.4 的 web.xml 时，必须指定一个整数。如果像在 <load-on-startup/> 中一样指定空的 <load-on-startup>，则 web.xml 将无法针对 web.xml 的 Servlet 2.4 模式进行验证，从而导致 Web 应用程序的部署失败。

向下兼容性问题。指定空的 <load-on-startup> 在基于 Servlet 2.3 的 web.xml 中仍起作用。

解决方法

在使用基于 Servlet 2.4 的 web.xml 时，指定 <load-on-startup>0</load-on-startup>，以表明 servlet 的装入顺序无关紧要。

6184122 

无法编译资源受限服务器上的 JSP 页面。 

已访问 JSP 页面但是无法对其进行编译，并且服务器日志包含错误消息“无法执行命令”和以下堆栈跟踪： 

at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher.exec
(Execute.java:655) at org.apache.tools.ant.taskdefs.Execute.launch
(Execute.java:416) at org.apache.tools.ant.taskdefs.Execute.execute
(Execute.java:427) at org.apache.tools.ant.taskdefs.compilers.
DefaultCompilerAdapter.executeExternalCompile(DefaultCompilerAdapter.
java:448) at org.apache.tools.ant.taskdefs.compilers.JavacExternal.
execute(JavacExternal.java:81) at org.apache.tools.ant.taskdefs.
Javac.compile(Javac.java:842) at org.apache.tools.ant.taskdefs.Javac.
execute(Javac.java:682) at org.apache.jasper.compiler.Compiler.
generateClass(Compiler.java:396)

解决方法

将 JSP 编译开关 "fork" 设置为 "false"。 

可以通过以下两种方式之一来实现： 

• 在全局范围内，将 ${S1AS_HOME}/domains/domain1/config/default-web.xml 中 JspServlet 的 fork 初始化参数设置为 false：

  <servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class> .... <init-param> <param-name>fork</param-name> <param-value>false</param-value> </init-param> .... </servlet>

• 在每个 Web 应用程序基础上，通过将 sun-web.xml 中的 fork JSP 配置属性设置为 false：

  <sun-web-app> <jsp-config> <property name="fork" value="false" /> </jsp-config> </sun-web-app>

以上任何一种设置都将阻止 ant 产生用于 javac 编译的新进程。

6188932 

Application Server 不支持 auth-passthrough Web Server 6.1 附加软件。

Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Update 2 添加了对 Sun Java System Application Server Enterprise Edition 7.1 附带的 auth-passthrough 插件函数所提供功能的支持。但是，在 Application Server Enterprise Edition 8.1 2005Q2 Update 2 中，auth-passthrough 插件功能的配置有所不同。

Application Server Enterprise Edition 7.1 中的 auth-passthrough 插件功能已经在两层部署方案中带来很大帮助，其中：

• Application Server 实例受公司防火墙之后的第二层防火墙的保护。

• 不允许客户机直接连接到 Application Server 实例。

在这种网络体系架构中，客户机连接到前端 Web 服务器，而该 Web 服务器配置有 service-passthrough 插件功能，会将 HTTP 请求转发到代理的 Application Server 实例以供处理。Application Server 只能从 Web 服务器代理接收请求，而决不会从任何客户机主机接收请求。因此，当部署在代理的 Application Server 实例上的任何应用程序查询客户机信息时，该应用程序将收到代理主机的信息（例如，当该应用程序查询客户机 IP 地址时，会收到代理主机的 IP），这是因为代理主机才是中继请求的真正发出主机。

在 Application Server Enterprise Edition 7.1 中，auth-passthrough 插件功能可在代理的 Application Server 实例上配置，以便使远程客户机信息能够直接由其上部署的所有应用程序使用，就像 Application Server 实例直接接收了请求，而不是通过运行 service-passthrough 插件的中间 Web 服务器接收请求。

在 Application Server Enterprise Edition 8.1 2005Q2 Update 2 中，可以通过将 domain.xml 中 <http-service> 元素的 authPassthroughEnabled 属性设置为 TRUE 来启用 auth-passthrough 功能，如下所示：

<property name="authPassthroughEnabled" value="true"/>

Application Server Enterprise Edition 7.1 中 auth-passthrough 插件功能的安全注意事项也同样适用于 Application Server Enterprise Edition 8.1 2005Q2 Update 2 中的 authPassthroughEnabled 属性。由于 authPassthroughEnabled 使我们能够覆盖可用于验证目的的信息（如发出请求的 IP 地址或 SSL 客户机证书），因此可以确保只有受信任的客户机或服务器才能连接到将 authPassthroughEnabled 设置为 TRUE 的 Application Server Enterprise Edition 8.1 2005Q2 Update 2 实例。作为一项预防措施，建议仅将公司防火墙之后的服务器的 authPassthroughEnabled 设置为 TRUE，而不要将可通过 Internet 访问的服务器的 authPassthroughEnabled 设置为 TRUE。

请注意，当代理 Web 服务器已配置了 service-passthrough 插件并且将请求转发到 authPassthroughEnabled 设置为 TRUE 的 Application Server 8.1 Update 2 实例时，Web 服务器代理上可能启用了 SSL 客户机验证，而在代理的 Application Server 8.1 Update 2 实例上却禁用了该验证。在这种情况下，代理的 Application Server 8.1 Update 2 仍会将请求当作通过了 SSL 验证，并向部署在其上的发出请求的所有应用程序提供客户机 SSL 证书。

6332486 

Developers Guide References NetBeans 3.6 for Debugging with IDE 应升级到 4.1 或更高版本的方案。 

《Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide》中的“Using an IDE” 一节介绍了如何使用 NetBeans 3.6 IDE 进行调试，但其实需要提供有关 NetBeans 4.1 或更高版本的说明。有关使用 NetBeans 3.6 之后版本的说明，请参见《Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide》中的“Using an IDE”一节。