test

Sun Java System Application Server Platform Edition 8.2 Release Notes

Chapter 3 Known Issues and Limitations

This chapter describes known problems and associated workarounds for the Sun Java System Application Server Platform Edition 8.2 product. If a summary statement does not specify a particular platform, the problem applies to all platforms. This information is organized into the following sections:

Administration

The package-appclient script does not work if domain1 is not present. (ID 6171458)

By default, there is a hard-coded value in $INSTALL/lib/package-appclient.xml for the AS_ACC_CONFIG variable for domain1 that is pointed to by asenv.conf. If domain1 is deleted and a new domain created, the AS_ACC_CONFIG variable is not updated with the new domain name, which causes the package-appclient script to fail.

Solution

Do one of the following:

Cannot restore backed-up domain with another name. (ID 6196993)

Mirroring of a domain on the same Application Server installation cannot be performed using the backup-domain and restore-domain commands because the domain cannot be restored using a different name than the original, even though the asadmin restore-domain command provides an option to rename the domain. Renaming the backed-up domain appears to succeed, but attempts to start the renamed domain fail because the entries in the domain configuration are not changed, and startserv and stopserv use the original domain name to set paths.

Solution

The domain name used for restore-domain must be the same as that used for the original backup-domain command. The backup-domain and restore-domain commands in Application Server 8.2 work only for backing up and restoring the same domain on the same machine.

Starting Application Server with additional JMX Agent is not supported. (ID 6200011)

J2SE 1.4.x, 5.0, or later can be configured on the Application Server. An integral feature of J2SE 5.0 platform is the ability to start a JMX agent. This is activated when you explicitly set system properties at the server startup.

Example values include:

name="com.sun.management.jmxremote" value="true"
name="com.sun.management.jmxremote.port" value="9999"
name="com.sun.management.jmxremote.authenticate" value="false"
name="com.sun.management.jmxremote.ssl" value="false"

After configuring JMX properties and starting the server, a new jmx-connector server is started within the Application Server VM. An undesirable side-effect of this is that the administration functions are affected adversely, and the Application Server administration GUI and CLI may produce unexpected results. The problem is that there are some conflicts between the built in jmx-connector server and the new jmx-connector server.

Solution

If using jconsole (or any other JMX-compliant client), consider reusing the standard JMX Connector Server that is started with Application Server startup.

When the server starts up, a line similar to the one shown below appears in the server.log. You can connect to the JMXServiceURL specified there and perform the same management/configuration operations after successfully providing the credentials; for example:

[#|2004-11-24T17:49:08.203-0800|INFO|sun-appserver-ee8.1|javax.enterprise.
system.tools.admin|_ThreadID=10;|ADM1501: Here is the JMXServiceURL for the 
JMXConnectorServer: [service:jmx:rmi:///jndi/rmi://hostname:8686/management/
rmi-jmx-connector]. This is where the remote administrative clients should 
connect using the JSR 160 JMX Connectors.|#]

For more information, refer to the Sun Java System Application Server 8.2 Administration Guide.

Cannot redeploy or undeploy the web module that is the default web module of any virtual server. (ID 6204799)

If the web module is specified as the default web module of a virtual server, and you try to redeploy or undeploy it, you will get the following error:

Trying to undeploy application from domain failed; Virtual Servers [server] 
have <WEB-MODULE-NAME\> as default web module. Please remove the default web
module references first. ; requested operation cannot be completed Virtual 
Servers [server] have <WEB-MODULE-NAME\> as default web module. Please
remove the default web module references first.

At this point, domain.xml is in an error state, and the Admin Console may not be able to display the table that shows the deployed web applications. The condition will persist even if the domain is stopped and started again.

Solution

Change the default web module.

ProcedureTo change the default web module

  1. Using the Admin Console, go to the virtual server page, and change the default web module to empty or specify another web module.

  2. Using the CLI, undeploy the web module by specifying domain as the target.


    # asadmin undeploy --target domain <WEB-MODULE-NAME\>

    The Admin Console should be fine now, and the web module can be deployed again, if desired.

FrameworkError exception after deploying a WAR and JAR to PE server via the AMX API in the Application Server GUI. (ID 6201462)

When an application is deployed on PE using the AMX API and not referenced, the Application Server GUI throws errors while displaying that application. AMX requires that you explicitly handle references for your applications. For example, when an application is deployed, the DeployedItemRefConfig needs to be explicitly created. To simplify the deployment process, references are assumed to be present in PE, which in turn causes the issue with Application Server GUI.

Solution

Always create the reference to a resource or application after creating it.

Java Home Setting inside Configuration does not take effect. (ID 6240672)

Application Server domains/servers do not use the JDK pointed to by java-home attribute of java-config element of associated configuration.

Solution

The JDK used by the Application Server processes for all the domains in a given server installation is determined by the appserver-installation-dir/config/asenv.conf file. The property AS_JAVA in this file determines the JDK used and is set at the time of installation. If a different JDK is to be used by Application Server processes after the installation is completed, this value can be modified to point to another JDK. Note that all domains in this installation will be affected by this change.

Note –

Manual changes to asenv.conf file are not checked for validity and hence care should be exercised while changing them. Check the product documentation for minimum JDK version requirements when modifying the value for AS_JAVA.

Selector.select() throws IOException. App Server startup fails. (ID 6322825)

In the current JDK code, the /dev/poll Selector allocates an array of 8192 pollfd entries for use by the Selector. This is exceeds the nofiles ulimit, causing it to fail with an “invalid argument” error. This in turn causes the App Server socket service that connects to MQ during startup to fail with an IOException because the selector.select() is broken.

Solution

Increase the pollfd file descriptor limit. There are two ways to do this:

  1. Execute ulimit -n 8193 on the shell as root.

  2. Increase the hard limit on the number of file descriptors to 8193 or higher:

    1. Check the hard limit with ulimit -n -H.

    2. If less than 8193, edit /etc/system, adding the set rlim_fd_max=8193 command.

    3. Reboot the machine.

Domain fails to start when create-domain master password has special characters. (ID 6345947)

Domain does not start when the domain's master password contains the percent (%) character.

Solution

The domain's master password should not contain a percent character (%). This applies when creating a new domain or changing the master password for an existing domain.

Specific Java System Properties are not handled correctly by AS 8.2 Startup. (ID 6372759)

Adding the following to the JVM proxy settings causes the server to not start:


<jvm—options>-Dhttp.proxyHost=webcache.east.sun.com</jvm—options>
<jvm—options> -Dhttp.proxyPort=8080</jvm—options>
<jvm—options>-Dhttp.nonProxyHosts="mssp.ctu.gov|*.ctu.gov|localhost"
</jvm—options>

Inserting a * character causes a No Class Def Found error (Exception in thread main java.lang.NoClassDefFoundError: com/sun/enterprise/security/store/IdentityManager). Inserting a | character causes the start script to timeout waiting for server to start.

This functionality is critical in order to support Application Server Deployments (and Portal deployments) that reside behind a firewall and need access to both external and internal servers. An example is the Portal Server URL Scraper. These settings are necessary in order to allow the URL Scraper to get content from external sources.

Solution

Edit install-dir/config/asenv.conf file, changing the line AS_NATIVE_LAUNCHER="true" to AS_NATIVE_LAUNCHER="false".

Application Client

This section describes known application client issues and associated solutions.

Library JAR packaged in Application Client Archive overwrites MANIFEST file. (ID 6193556)

If you have a top level JAR file inside your client JAR (in this case, reporter.jar), when you deploy the client JAR, the MANIFEST file for that JAR overwrites the MANIFEST file for the client JAR.

Solution

None at this time.

Dynamic content technology such as CGI-bin and SHTML functionality not supported. (ID 6373043)

Dynamic content technologies, such as CGI-bin and SHTML, are no longer supported.

Solution

Use JSP and Web service technologies instead.

Database Driver

This section describes the known database driver issues and associated solutions.

DB2 Server has connection growing after idle time-out with DB2 Type II driver (ID 2082209/5022904)

After porting applications from another application server, physical connections are not being closed properly after the connections timing out. This problem is seen with the DB2 8.1.x version of the Client libraries (Type II) Driver against the same DB2 7.1.x Database Server.

Solution

Set the SteadyPoolSize and MaxPoolSize to the same number, and in addition, set the Idle Connection timeout also to 0 (zero). This disables the timing-out of idle connections and the user will have the full set of connections available.

Deploytool

This section describes known Deploytool issues and associated solutions.

Deploytool often will not create message-destination elements in the following Sun deployment descriptors (ID 6197393):

Solution

To edit an existing JNDI Name of a Message Destination:

ProcedureTo edit an existing JNDI name

  1. Delete the existing JNDI Name by leaving the JNDI Name text field blank and pressing Enter.

  2. Type the new JNDI Name and press Enter.

  3. Review the Sun descriptor by clicking Tools\>Descriptor Viewer\>Application Server Descriptor.

  4. Save the application by clicking File\>Save.

    If the JNDI Name is not saved to the Sun descriptor:

  5. Restart deploytool.

  6. On the Message Destinations tab, select a Message Destination or add a new Message Destination.

  7. Enter the JNDI Name for the Message Destination in the Sun-specific JNDI Name text field, and then press Enter.

  8. Review the Sun descriptor by clicking Tools\>Descriptor Viewer\>Application Server Descriptor.

  9. Save the application by clicking File\>Save.

    Repeat the above steps each time a value needs to be entered in the Sun-specific JNDI Name on the Message Destinations tab, unless a value is being entered in the JNDI Name text field for the first time during a deploytool session.

“Home” incorrectly translated as “installation directory” in Deploytool for Simplified Chinese. (ID 6203658)

When you create an Enterprise Bean in deploytool, and then navigate to the Transaction or Security tab for the bean node, the “Local Home” and “Remote Home” labels are incorrectly translated as “Local Installation Directory” and “Remote Installation Directory.”

Documentation

This section describes known documentation issues and associated solutions.

Some documented monitoring features do not apply to Platform Edition. (ID 6202255)

The documentation for AMX (Application Server Management eXtenstions) does not specify some monitoring features that are not available in Application Server Platform Edition 8.2. Specifically, the components that cannot be monitored in the Platform Edition are as follows:

Solution

None needed. These statistics are not relevant for Platform Edition.

AppservPasswordLoginModule referenced as AbstractPasswordLoginModule in documentation (ID 6229682)

The Realm Configuration in Sun Java System Application Server Platform Edition 8.2 Developer’s Guide section in Chapter Chapter 2, Securing Applications, in Sun Java System Application Server Platform Edition 8.2 Developer’s Guide in theSun Java System Application Server Platform Edition 8.2 Developer’s Guide incorrectly refers to extending com.sun.appserv.AbstractLoginModule, however this class is now named com.sun.appserv.AppservLoginModule.

Solution

Refer to com.sun.appserv.AppservLoginModule instead of com.sun.appserv.AbstractLoginModule.

Incorrect -W short option for --passwordfile in 8.2 PE man pages. (ID 6373588)

There should be no short option for --passwordfile. Currently -W --passwordfile is documented in the man pages. This is incorrect.

Solution

Do not attempt to use the —W option with --passwordfile with Application Server 8.2 Platform Edition. The short option is scheduled to be added to a future Application Server release.

The Javadoc for several AMX interfaces and methods is either missing or incorrect (several IDs):

Documentation on getting a physical Connection from a wrapped Connection is no longer correct (ID 6486123)

As a result of other defects (possibly 6295215) the code provided in the Obtaining a Physical Connection from a Wrapped Connection in Sun Java System Application Server Platform Edition 8.2 Developer’s Guide section of Chapter 11, Using the JDBC API for Database Access, in Sun Java System Application Server Platform Edition 8.2 Developer’s Guide is not correct. Specifically, the line:


Connection drivercon = ds.getConnection(con);

should now read:


Connection drivercon = ((com.sun.gjc.spi.DataSource)ds).getConnection(con);

Installation

This section describes known installation/uninstallation issues and associated solutions.

Intermittent failure to render the Next navigation button on installer and uninstaller Welcome screen. (ID 4977191)

This problem has been reported intermittently on the Solaris x86 platform, but it is possible that it also affects Solaris SPARC and Linux platforms.

The problem is that the installer\qs or uninstaller\qs first screen correctly displays the full text and “Help” and “Cancel” buttons, but the “Next” button necessary to navigate to the next screen is not visible. Although button is not visible, its area is active and if you click on it, navigation to the next screen proceeds normally. The cause of the problem is intermittent J2SE GUI repaint issue.

Solution

One workaround is to click on the Next button area just to the left of the Help button. Another workaround is to force repainting of the screen by resizing it slightly or by minimizing and restoring the installer window. After repainting, the missing Next button will become visible.

Installation shutdown hanging on some Linux systems after clicking the Finish button. (5009728)

This problem has been observed on several Linux systems. It is most common on Java Desktop System 2 but has also been observed on RedHat distributions.

After clicking the Finish button on the last installer screen, the installer fails to launch a browser window containing the product About page or product registration page, and hangs indefinitely, not returning the command prompt.

Solution

Exit the installer by pressing Ctrl+C in the terminal window in which the installer was started. After doing this, browser window containing product About page or registration page will sometimes be launched, but if it does not show up, start the browser and enter following URL in order to review About page:

file://install_dir/docs/about.html

If you also selected the installation option to register the product, follow the link to registration page available on product About page.

Intermittent J2SE detection and bootstrap issues in install wrapper on Linux. (6172980)

The setup executable that launches the Linux installer sometimes hangs. Instead of resolving the J2SE location and starting the install wizard, the wrapper hangs and returns the following messages:

Chcking available disk space....
Checking Java(TM) 2 Runtime Environment....
Extracting Java(TM) 2 Runtime Environment....
Deleting temporary files.....

This issue is seen only in some versions of Linux, and seems to depend on environment settings, especially the presence of the JAVA_HOME variable.

Solutions

To work around this issue:

ProcedureTo work around the bootstrap issues on Linux

  1. Unset the JAVA_HOME variable by running unset or unsetenv depending on your shell.

  2. Run setup with the -javahome option to specify the JAVA_HOME used by the installer.

Application Server does not support NFS.

This versions of Application Server does not support Network File System (NFS).

Solution

None.

Lifecycle Management

This section describes known lifecycle management issues and associated solutions.

After setting the ejb-timer-service property minimum-delivery-interval to 9000, an attempt to set the ejb-timer-service property redelivery-interval-in-mills to 7000 causes the set command to fail with the following error: (ID 6193449)

[echo] Doing admin task set
[exec] [Attribute(id=redelivery-interval-internal-in-millis) : Redelivery-
Interval (7,000) should be greater than or equal to Minimum-delivery-
interval-in-millis (9,000)]
[exec] CLI137 Command set failed.

Solution

Use the default values for these properties, as follows:

minimum-delivery-interval(default)=7000
redelivery-interval-in-millis(default)=5000

Values other than these defaults will generate an error.

Logging

This section describes known logging issues and solutions.

Setting debug statement for access.failure causes hanging in Application Server startup. (ID 6180095)

Setting the java.security.debug option for the JVM will cause the server instance startup to freeze with a deadlock; for example, setting the following in domain.xml causes the problem:

<jvm-options\>-Djava.security.debug=access,failure</jvm-options\>

Solution

None at this time. Please avoid setting this flag.

Sample Applications

This section describes known and associated solutions related to the sample code included with the Application Server 8.2 product.

managementws sample needs to update MANIFEST.MF references from castor-0.9.3.9-xml.jar to castor-0.9.9.1.jar. (ID 6363339)

When running the verifier on <install_dir>/samples/webservices/jaxrpc/apps/managementws, you encounter the following warnings:


[exec] WARNING: /var/tmp/exploded20051214111425/managementws/ \
managementwsEjb_jar contains library/castor-0.9.3.9-xml.jar in Class-Path 
manifest attribute, but it is not found in ear file
[exec] Dec 14, 2005 11:14:30 AM Archive getBundledArchives
[exec] WARNING: /var/tmp/exploded20051214111425/managementws/ \
managementwsEjb_jar contains library/castor-0.9.3.9-xml.jar in Class-Path
manifest attribute, but it is not found in ear file

The Castor jar was updated in the Application Server 8.2 release, so all references to the older castor-0.9.3.9-xml.jar should be changed to point to the newer castor-0.9.9.1.jar. Specifically you need to change references in the MANIFEST.MF files to use castor-0.9.9.1.jar instead of the older castor-0.9.3.9-xml.jar.

Solution

Change the following references to the older Castor jar to point to the new Castor jar:

Old: 


src/conf/MANIFEST.MF:Class-Path: library/castor-0.9.3.9-xml.jar
src/conf/MANIFEST.MF:Name: library/castor-0.9.3.9-xml.jar
managementws-ejb/src/conf/MANIFEST.MF:Class-Path: \
library/castor-0.9.3.9-xml.jar

New: 


src/conf/MANIFEST.MF:Class-Path: library/castor-0.9.9.1.jar
src/conf/MANIFEST.MF:Name: library/castor-0.9.9.1.jar
managementws-ejb/src/conf/MANIFEST.MF:Class-Path: \
library/castor-0.9.9.1.jar

Next, clean up the build.xml file so it does not copy the Castor .jar to install_dir/lib during deployment and remove it during undeployment. The following are diffs of the old and new build.xml files.

% cvs diff build.xml Index: build.xml
===================================================================
RCS file: /m/jws/samples/samples8x/webservices/jaxrpc/apps/managementws/ \
managementws-standalone-client/ Attic/build.xml,v retrieving revision \
1.1.2.3
diff -r1.1.2.3 build.xml
80,89d79
<   <target name="remove_castor_from_classpath">
<       <delete file="${com.sun.aas.installRoot}/lib/castor-0.9.9.1.jar"/>
<   </target>
<   <target name="add_castor_to_classpath">
<       <delete file="${com.sun.aas.installRoot}/lib/castor-0.9.9.1.jar"/>
<       <copy file="../lib/castor-0.9.9.1.jar" \
            todir="${com.sun.aas.installRoot}/lib" />
<   </target>
<
<   <target name="setup" depends="add_castor_to_classpath, restart.server"/>
<  jbenoit/galapago 196 >pwd
/net/galapago.east/files/share/8.2ws/samples/samples8x/webservices/jaxrpc \
/apps/managementws/managementws-standalone-client
jbenoit/galapago 197 >cd ..
jbenoit/galapago 198 >cvs diff build.xml
Index: build.xml
===================================================================
RCS file: /m/jws/samples/samples8x/webservices/jaxrpc/apps/managementws/ \
Attic/build.xml
v retrieving revision 1.1.2.4
diff -r1.1.2.4 build.xml
28,36d27
<   <target name="setup">
<       <ant antfile="build.xml" inheritAll="true" dir="${sample.name}$ \
{standalone-client-dir-suffix}" target="setup"/>
<   </target>
<   
<   <target name="unsetup">
<       <ant antfile="build.xml" inheritAll="true" dir="${sample.name}$ \
{standalone-client-dir-suffix}" target="remove_castor_from_classpath"/>
<   </target> 
<
<
53,54c44,45
<   <target name="deploy"   depends="select_binary_common, deploy_common, 
    setup" />
<   <target name="undeploy" depends="init,  undeploy_common, unsetup"/>
---
>   <target name="deploy"   depends="select_binary_common, deploy_common" />
>   <target name="undeploy" depends="init,  undeploy_common"/>

Security

This section describes known security issues and solutions.

WS security: appclient container is not properly integrated with JAXRPC client runtime. (ID 6325469)

The application client does not pass the user name and password to another Web Service client.

Solution

Pass the user name/password combination, if required, explicitly to the client program, as follows:

((Stub)yourWSPort)._setProperty(Stub.USERNAME_PROPERTY, "yourUsername");
((Stub)yourWSPort)._setProperty(Stub.PASSWORD_PROPERTY, "yourPassword");

Upgrade Utility

This section describes known Upgrade utility issues and associated solutions.

Domains created in custom-path other than install_dir/domains directory are not upgraded directly while upgrading from Application Server Platform Edition 8 to Application Server Platform Edition 8.2. (ID 6165528)

When running the Upgrade Utility and identifying the install_dir as the source installation directory, the upgrade process upgrades only those domains that are created under install_dir/domains directory. Domains created in other locations are not upgraded.

Solution

Before starting the upgrade process, copy all the domain directories from their different locations to the install_dir/domains directory.

Port conflict when starting domain1 or samples domain after upgrading from 8.0 Platform Edition to 8.2 Platform Edition. (ID 6202188)

After upgrading an 8.0 Application Server with multiple domains, the domains may not be able to start simultaneously due to having the same port number configured for the JMX connector.

Solution

Change the port value.

ProcedureTo change the port value

  1. Check the install dir /domains/domain1/config/domain.xml file, for the following entry:


    <jmx-connector accept-all="false" address="0.0.0.0" auth-realm-name=
"admin-realm" enabled="true" name="system" port="8686" protocol="rmi_jrmp" 
security-enabled="false"/\>" -- and in file <as 8.1 install dir\>
/domains/domain1/samples/config/domain.xml, notice it used the same port 
"8686", so it failed to start domain due to port conflict.

  2. Change the port value 8686 to 8687, and then restart domain1.

The installer running “Upgrade in place” fails to start upgrade tool on some Linux systems after clicking on the “Start Upgrade Wizard” button. (6207337)

This problem has been observed on several Linux systems, it is most common on Java Desktop System 2 but has also been observed on RedHat distributions.

After clicking the Start Upgrade Tool button on the final installer screen, the installer fails to launch the upgrade tool to complete the upgrade process, and hangs indefinitely, not returning the command prompt.

Solution

This issue is not encountered if command line installation mode is used to run upgrade in place.

ProcedureTo use command line installation mode

  1. If you ran upgrade in place in GUI mode and encountered this problem, exit the installer by pressing Ctrl+C in the terminal window in which the installer was started.

  2. Start upgrade tool from the terminal window, using following command:


    install_dir/bin/asupgrade --source install_dir/domains --target install_dir 
--adminuser adminuser--adminpassword adminpassword --masterpassword changeit

    adminuser and adminpassword should match the values used for the installation you are upgrading.

  3. When the upgrade tool completes the upgrade process you can also start the browser and enter following URL in order to review About page:

    file://install_dir/docs/about.html

    If you also selected the installation option to register the product, follow the link to registration page available on product About page.

Garbage characters displayed in Results panel after upgrade (ID 6376140)

When upgrading from the multilanguage version of Application Server 8.2 to a later version using some locales, the Results panel may display garbage characters, and the /opt/SUNWappserver/domains/upgrade.log file may also display garbage characters.

Solution

None at this time. This problem will be fixed in a future Application Server release.

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.

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:

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

Received malformed Fast Infoset documents can disable Fast Infoset support for JAX-RPC deployed services. (ID 6368670)

If a nonconformant Fast Infoset encoded SOAP message is sent to a JAX-RPC service then the service will correctly fault in response. However, subsequent conformant Fast Infoset encoded SOAP messages sent to the same service or a service deployed using the same JAX-RPC runtime may fault incorrectly.

Solution

The following workarounds are possible: