Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Update 2 Release Notes

- Previous: Upgrade Utility

# Web Container

This section describes known web container issues and associated solutions.

Bug ID | Summary
--- | ---
5004315 | On Windows, deploying an application using `--precompilejsp=true` can lock JAR files in the application, causing later undeployment or redeployment to fail. If you request precompilation of JSPs when you deploy an application on Windows, later attempts to undeploy that application or to redeploy it (or any application with the same module ID) will not work as expected. The problem is that JSP precompilation opens JAR files in your application but does not close them, and Windows prevents the undeployment from deleting those files or the redeployment from overwriting them. Note that undeployment succeeds to a point, in that the application is logically removed from the Application Server. Also note that no error message is returned by the `asadmin` utility, but the application's directory and the locked jar files remain on the server. The server's log file will contain messages describing the failure to delete the files and the application's directory. Attempts to redeploy the application after undeploying fail because the server tries to remove the existing files and directory, and these attempts also fail. This can happen if you try to deploy any application that uses the same module ID as the originally deployed application, because the server uses the module ID in choosing a directory name to hold the application's files. Attempts to redeploy the application without undeploying it first will fail for the same reasons. Diagnostics If you attempt to redeploy the application or deploy it after undeploying it, the asadmin utility returns an error similar to the one below.
    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.
Solution If you specify `--precompilejsps=false` (the default setting) when you deploy an application, then this problem will not occur. Be aware that the first use of the application will trigger the JSP compilation, so the response time to the first request will be longer than for later requests. Note also that if you do precompile, you should stop and restart the server before undeploying or redeploying the application. The shutdown frees the locked JAR files so the undeployment or redeployment after the restart can succeed.
6172006 | Unable to deploy WAR with Servlet 2.4-based `web.xml` that contains an empty `<load-on-startup>` element. The optional load-on-startup servlet element in a `web.xml` indicates that the associated servlet is to be loaded and initialized as part of the startup of the web application that declares it. The optional content of this element is an integer indicating the order in which the servlet is to be loaded and initialized with respect to the web application's other servlets. An empty `<load-on-startup>` indicates that the order is irrelevant, as long as the servlet is loaded and initialized during the startup of its containing web application. The Servlet 2.4 schema for `web.xml` no longer supports an empty `<load-on-startup>`, meaning that an integer must be specified when using a Servlet 2.4 based `web.xml`. If specifying an empty `<load-on-startup>`, as in `<load-on-startup/>`, the `web.xml` will fail validation against the Servlet 2.4 schema for `web.xml`, causing deployment of the web application to fail. Backwards compatibility issue. Specifying an empty <load-on-startup> still works with Servlet 2.3 based `web.xml`. Solution Specify `<load-on-startup>0</load-on-startup>` when using a Servlet 2.4 based `web.xml` to indicate that servlet load order does not matter.
6184122 | Unable to compile JSP page on resource constrained servers. The JSP page is accessed but fails to compile, and the server log contains the error message "Unable to execute command" with the following stack trace:
    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)
- Solution Set the JSP compilation switch "fork" to "false." This can be done either of two ways: Globally, by setting the fork init parameter of the JspServlet in `${S1AS_HOME}/domains/domain1/config/default-web.xml` to 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>
- On a per-web application basis, by setting the fork JSP configuration property in `sun-web.xml` to false:
      <sun-web-app> <jsp-config> <property name="fork" value="false" />
      </jsp-config> </sun-web-app>
Either setting will prevent ant from spawning a new process for `javac` compilation.
6188932 | Application Server does not support `auth-passthrough` Web Server 6.1 Add-On. The Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Update 2 adds support for the functionality provided by the `auth-passthrough` plugin function available with Sun Java System Application Server Enterprise Edition 7.1. However, in Application Server Enterprise Edition 8.1 2005Q2 Update 2, the `auth-passthrough` plugin feature is configured differently. The `auth-passthrough` plugin function in Application Server Enterprise Edition 7.1 has been useful in two-tier deployment scenarios, where: Application Server instance is protected by a second firewall behind the corporate firewall. No client connections are permitted directly to the Application Server instance. In such network architectures, a client connects to a front-end web server, which has been configured with the `service-passthrough` plugin function and forwards HTTP requests to the proxied Application Server instance for processing. The Application Server instance can only receive requests from the web server proxy, but never directly from any client hosts. As a result of this, any applications deployed on the proxied Application Server instance that query for client information, such as the client's IP address, will receive the proxy host IP, since that is the actual originating host of the relayed request. In Application Server Enterprise Edition 7.1, the `auth-passthrough` plugin function could be configured on the proxied Application Server instance in order to make the remote client's information directly available to any applications deployed on it; as if the proxied Application Server instance had received the request directly, instead of via an intermediate web server running the `service-passthrough` plugin. In Application Server Enterprise Edition 8.1 2005Q2 Update 2, the `auth-passthrough` feature may be enabled by setting the `authPassthroughEnabled` property of the `<http-service>` element in `domain.xml` to TRUE, as follows:
    <property name="authPassthroughEnabled" value="true"/>
The same security considerations of the `auth-passthrough` plugin function in Application Server Enterprise Edition 7.1 also apply to the `authPassthroughEnabled` property in Application Server Enterprise Edition 8.1 2005Q2 Update 2. Since `authPassthroughEnabled` makes it possible to override information that may be used for authentication purposes (such as the IP address from which the request originated, or the SSL client certificate), it is essential that only trusted clients or servers be allowed to connect to an Application Server Enterprise Edition 8.1 2005Q2 Update 2 instance with `authPassthroughEnabled` set to TRUE. As a precautionary measure, it is recommended that only servers behind the corporate firewall should be configured with `authPassthroughEnabled` set to TRUE. A server that is accessible through the Internet must never be configured with `authPassthroughEnabled` set to TRUE. Notice that in the scenario where a proxy web server has been configured with the `service-passthrough` plugin and forwards requests to an Application Server 8.1 Update 2 instance with `authPassthroughEnabled` set to TRUE, SSL client authentication may be enabled on the web server proxy, and disabled on the proxied Application Server 8.1 Update 2 instance. In this case, the proxied Application Server 8.1 Update 2 instance will still treat the request as though it was authenticated via SSL, and provide the client's SSL certificate to any deployed applications requesting it.
6332486 | Developers Guide References NetBeans 3.6 for Debugging with IDE, should be upgraded to 4.1 or later scenario. The Using an IDE in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide section of the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer’s Guide describes using the NetBeans 3.6 IDE for debugging, but it should instead provide instructions for NetBeans 4.1 or later. For instructions on using a later version than NetBeans 3.6, see the Using an IDE in Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide section of the Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide.

- Previous: Upgrade Utility

- © 2010, Oracle Corporation and/or its affiliates