test

Sun Java System Application Server Enterprise Edition 8.2 Release Notes for Microsoft Windows

Web Container

This section describes known web container issues and associated solutions.

No Support For Apache and IIS for Load Balancer Plug-in

Sun Java ES 5 Application Server does not support Apache and IIS (non-Sun web container) for load balancer plug-in. Sun Java ES installs Sun Java System Web Server for load balancer plug-in configuration.

Deployment of Application Using --precompilejsp=true Can Lock JAR Files (ID 5004315)

On Windows platform, 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. 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 scenario 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 following:


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, this problem does not occur. Be aware that the first use of the application triggers the JSP compilation, so the response time to the first request is 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.

Unable to Deploy WAR with Servlet 2.4-Based web.xml That Contains Empty <load-on-startup> Element (ID 6172006)

The optional load-on-startup servlet element in a web.xml file 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> element 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 file. If specifying an empty <load-on-startup>, as in <load-on-startup/>, the web.xml file fails validation against the Servlet 2.4 schema for web.xml, causing deployment of the web application to fail.

Backward 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.

Unable to Compile JSP Page on Resource-Constrained Servers. (ID 6184122)

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."

You can activate this setting in either of two ways:

Either setting prevents Ant from spawning a new process for javac compilation.

Application Server Does Not Support auth-passthrough Web Server 6.1 Add-On (ID 6188932)

The Sun Java System Application Server Enterprise Edition 8.2 adds support for the functionality provided by the auth-passthrough plug-in function available with Sun Java System Application Server Enterprise Edition 7.1. However, in Application Server Enterprise Edition 8.2, the auth-passthrough plug-in feature is configured differently.

The auth-passthrough plug-in function in Application Server Enterprise Edition 7.1 has been useful in two-tier deployment scenarios, with the following constraints:

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 receive requests only from the web server proxy, but never directly from any client hosts. As a result, 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, as that is the actual originating host of the relayed request.

In Application Server Enterprise Edition 7.1, the auth-passthrough plug-in 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 plug-in.

In Application Server Enterprise Edition 8.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 plug-in function in Application Server Enterprise Edition 7.1 also apply to the authPassthroughEnabled property in Application Server Enterprise Edition 8.2. Since authPassthroughEnabled enables the overriding of information that may be used for authentication purposes (such as the IP address from which the request originated, or the SSL client certificate). Therefore, only trusted clients or servers should be allowed to connect to an Application Server Enterprise Edition 8.2 instance with authPassthroughEnabled set to TRUE. As a precautionary measure, configure only servers behind the corporate firewall 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 plug-in and forwards requests to an Application Server 8.1 Update 2 instance with authPassthroughEnabled set to TRUE, SSL client authentication can 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 still treats the request as though it was authenticated through SSL, and provide the client's SSL certificate to any deployed applications requesting it.

HTTP Listener Created With --enabled=false DoesNot Disable the Listener (ID 6190900)

When an httplistener is created with the --enabled=false flag, the listener does not become disabled. The flag --enabled does not have any effect when used at the same time the listener is created.

Solution

Create the listener in an enabled state, then disable it manually later.