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

- Previous: Upgrade Utility
- Next: How to Report Problems and Provide Feedback

## Web Container

This section describes known web container issues and associated solutions.

### Deploying an application using `--precompilejsp=true` can lock JAR files in the application, causing later undeployment or redeployment to fail. (Windows only) (ID 5004315)

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\qs` directory and the locked jar files remain on the server. The `server\qs` log file will contain messages describing the failure to delete the files and the `application\qs` 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\qs 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\qt be deleted

#### Solutions

If you specify `--precompilejsps=false` (the default setting) when you deploy an app, 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.

### Unable to deploy WAR with Servlet 2.4-based `web.xml` that contains an empty `<load-on-startup\>` element. (ID 6172006)

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\qs` 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.

### Using the AMX API, removing a J2EE application reference from a server removes the application, but the application is still accessible. (ID 6173248)

When using the AMX API, removing a reference to an application without first explicitly stopping the application results in that application still being accessible. This behavior is by design, and is a documentation omission.

#### Solution

To remove an application so it is no longer accessible:

#### To remove an application

1. Stop the application.

2. Remove the reference to the application.

3. Undeploy the application.

### 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`.

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.

### Performance degradation on multi-CPU machines. (ID 6194026)

The default configuration of the Application Server PE does not perform optimally on multi-CPU machines. A trade-off is made so that startup is faster, but this can negatively impact the performance of web applications.

#### Solution

Configure the Application Server to use the following JVM option:

    -Dcom.sun.enterprise.server.ss.ASQuickStartup=false

- Previous: Upgrade Utility
- Next: How to Report Problems and Provide Feedback

- © 2010, Oracle Corporation and/or its affiliates