Sun Java System Application Server Platform Edition 9 Release Notes

Chapter 3 Known Issues and Limitations

This section describes known problems and associated workarounds for the Sun Java System Application Server Platform Edition 9 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:

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 9 Administration Guide.

display-error-statistics brings negative stats

The Admin Console GUI is able to differentiate between a real zero (0) and a state for which statistics are not available (N/A). The command-line interface currently displays negative 1 (-1) instead of N/A. For example, the following output for the display-error-statics command shows —1 instead of N/A.


# asadmin display-error-statistics
Please enter the admin user name>admin
Please enter the admin password>
Timestamp                               Severity  Warning 
---------------------------------------------------------
1143659837750(Mar 29, 2006 11:17:17 AM)     0        0       
1143656237750(Mar 29, 2006 10:17:17 AM)     0        0       
1143652637750(Mar 29, 2006 9:17:17 AM)      -1       -1      
1143649037750(Mar 29, 2006 8:17:17 AM)      -1       -1      
1143645437750(Mar 29, 2006 7:17:17 AM)      -1       -1      
---------------------------------------------------------
Command display-error-statistics executed successfully.

Solution

Use the Admin Console GUI to display error statistics. This issue will be fixed in a later release.

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.

Windows platform – APPCPATH is not being set in the classpath (ID 6419847)

It has been observed that the appclient.bat command is not accepting the APPCPATH when running on Windows. The problem can be traced to quotes around the APPCPATH statement in the apppclient.bat file. For example, the following statement fails:


set CLASSPATH="%JAXP_IMPL_JARS%";%JVM_CLASSPATH%
if not %APPCPATH%x == x set CLASSPATH=%CLASSPATH%;"%APPCPATH%"

Whereas the following statement works correctly:


set CLASSPATH=%JAXP_IMPL_JARS%;%JVM_CLASSPATH%
if not %APPCPATH%x == x set CLASSPATH=%CLASSPATH%;%APPCPATH%

Solution

Remove the double quotes that surround the references to APPCPATH (and JAXP_IMPL_JARS).

Installation

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

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.

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.

Java Persistence API

This section lists known issues and associated solutions related to the Java Persistence API.

An UPDATE or DELETE query using a subquery in the WHERE clause results in a NullPointerException during query compilation.

See https://glassfish.dev.java.net/issues/show_bug.cgi?id=572 for more information.

Solution

Do not use this type of query.

The query compiler does not check all the rules as defined in the Java Persistence Language specification.

The query compiler does not check all the rules as defined in the Java Persistence Language chapter of the specification. In particular, it does not check:

An invalid query may compile but may cause a SQLException at runtime. Or it might happen that the underlying database is less restrictive and supports the generated SQL, but executing the same query on a different database fails with a SQLException.

Solution

Verify the above conditions manually.

A query grouping by a JOIN variable and directly selecting the JOIN variable might result in a SQLException

A query grouping by a JOIN variable and directly selecting the JOIN variable might result in a SQLException complaining about non-grouping expressions being selected. For more information, see https://glassfish.dev.java.net/issues/show_bug.cgi?id=197. For example:


SELECT AVG(o.totalPrice), c FROM Order o JOIN o.customer c GROUP BY c

Solution

A possible workaround is to directly navigate the relationship instead of defining a JOIN variable; for example:


SELECT AVG(o.totalPrice), o.customer FROM Order GROUP BY o.customer

In some cases, the query compiler throws a misleading error message, because it mentions the wrong token in the error message.

For more information, see https://glassfish.dev.java.net/issues/show_bug.cgi?id=550.

Solution

Manually verify what is wrong in the query.

Two persistence units containing the same class cannot currently be deployed in the same EAR file.

Solution

Use different class names.

You cannot list MappedSuperclass explicitly using class element in persistence.xml.

For more information, see https://glassfish.dev.java.net/issues/show_bug.cgi?id=558.

Solution

Do not list MappedSuperclass explicitly.

Entity mapping @ManyToMany fails on inherited class.

For more information, see https://glassfish.dev.java.net/issues/show_bug.cgi?id=578.

Solution

Do not use ManyToMany relationship in a subclass.

Using List<> for a relationship causes StringIndexOutOfBoundException in MetadataHelper.getAttributeNameFromMethodName.

For more information, see https://glassfish.dev.java.net/issues/show_bug.cgi?id=557.

Solution

Use java.util.Collection instead.

Unable to map null database values to primitives.

Solution

Use Java wrapper types for mapping to nullable database columns.

Accessing a LAZY initialized relationship from client side sometimes causes a NullPointerException.

For more information, see https://glassfish.dev.java.net/issues/show_bug.cgi?id=404.

Solution

Access LAZY initialized relationship in server-side code before returning an instance to the client.

A query selecting a relationship field does not include null in the query result.

A query selecting a relationship field does not include null in the query result when the value of the relationship field is null. This entry is instead skipped from the query result; for example:


SELECT o.customer FROM Order o WHERE ...

See https://glassfish.dev.java.net/issues/show_bug.cgi?id=637 for more information.

Solution

Select a state field from the related instance.


SELECT o.customer.customerId FROM Order o WHERE ...

A query selecting a JOIN identification variable defined for a single valued relationship field may result in invalid SQL.

For example:


SELECT c FROM Order o LEFT OUTER JOIN o.customer c

See https://glassfish.dev.java.net/issues/show_bug.cgi?id=638 for more information.

Solution

Select a state field from the related instance.


SELECT c.customerId FROM Order o LEFT OUTER JOIN o.customer c

EntityManager.find() erroneously throws an IllegalArgumentException

EntityManager.find() erroneously throws an IllegalArgumentException for an entity that is a subclass of another entity if the primary key class is defined by an @IdClass annotation. See https://glassfish.dev.java.net/issues/show_bug.cgi?id=595 for more information.

Solution

Use the class of the topmost superclass as the argument to the find() method, and cast the result to the subclass.

Cannot persist an entity with relationship field set to a java.util.HashSet.

See https://glassfish.dev.java.net/issues/show_bug.cgi?id=643 for more information.

Solution

Use java.util.ArrayList as the initial value.

JavaServer Faces

This section describes known JavaServer Faces (JSF) issues and associated solutions. Note that you can find additional information about the JSF project and submit any JSF bugs you may encounter by going to the JSF project Web site.

JSF 1.1 - 1.2 Spec Violation: Variable and Property Resolvers (ID 6419278)

JavaServer Faces Technology Applications that use the VariableResolver decoration to extend the functionality of the Expression Language may not work properly.

Section 10.4.5 of the JavaServer Faces Technology Specification states:

“When providing a replacement for the default PropertyResolver, VariableResolver, ActionListener, NavigationHandler, ViewHandler, or StateManager, the decorator design pattern is leveraged, so that if you provide a constructor that takes a single argument of the appropriate type, the custom implementation receives a reference to the implementation that was previously fulfilling the role. In this way, the custom implementation is able to override just a subset of the functionality (or provide only some additional functionality) and delegate the rest to the existing implementation.”

In Application Server 9, a custom VariableResolver implementation will receive a “previous” VariableResolver that does not fully fulfill the role of variable resolution.

Solution

Instead of delegating to the “previous” VariableResolver to resolve an expression, we recommend creating an ValueExpression and evaluating it.


Example 3–1 Evaluating a ValueExpression

public class CustomVR extends VariableResolver {

    private VariableResolver previous = null;

    public CustomVR(VariableResolver previous) {
	this.previous = previous;
    }
  
    public Object resolveVariable(FacesContext context, String name)
	throws EvaluationException {
	Object result = null;
	
	// Do some action that may resolve the variable.  If not, you
	// may be tempted to simply do: 

	// result = previous.resolveVariable(context, name);

	// But this would not work due to bug 6419278.  A fix is
	// available, please see the Release Notes.  However, a
	// workaround is the following.

	ValueExpression ve = context.getApplication().getExpressionFactory(). \
createValueExpression(context.getELContext(), "#{" + name + "}", Object.class);
	try {
	    result = ve.getValue(context.getELContext());
	}
	catch (PropertyNotFoundException pnfe) {
	    throw new EvaluationException(pnfe);
	}
	catch (ELException ele) {
	    throw new EvaluationException(ele);
	}
	return result;

    }
}

Upgrade

This section describes known issues and associated solutions related to upgrading and using the Upgrade Tool.

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 9. (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.

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.

Upgrade Tool does not transfer all JVM options (ID 6409650)

The Upgrade Tool does not transfer JVM options, such as those related to stack size and heap size because they should retain the values specified during installation. This is because the values for these options are likely to be set for specific reasons for the current version of the product. The Upgrade Tool will log a message indicating which options have not been transferred.

Copy static documents in docroot directory after upgrade (ID 6409641)

After you upgrade your Application Server installation, copy any static documents in the docroot directory to the new docroot directory. If you did an in-pace upgrade, copy the documents from the backed-up domain directory under the domaindir of the installation.

Must close Application Server files when running Upgrade Tool on Windows

While running Upgrade Tool on Windows, you must close all files in the installation being upgraded. If a file is left open, then the Upgrade Tool has been observed to hang.

Username Token not encrypted if we use XWSClientProvider and XWSServerProvider. (ID 6409652)

To use the XWSCLientProvider and XWSServerProvider in an upgraded Application Server , you must modify the deployment descriptors of the applications that use these providers, to refer to XWSClientProvider and XWSServerProvider.

The deployment decriptors that you must change are sun-web.xml and sun-ejb-jar.xml. The Upgrade Tool logs a message in the upgrade log if it finds ClientProvider and ServerProvider in the sun-web.xml or sun-ejb-jar.xml.

Web Container

This section describes known web container issues and associated solutions.

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.


Note –

This limitation applies to Servlet 2.4-based web.xml only; it is possible to specify an empty load-on-startup element using a Servlet 2.5-based web.xml.


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.

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:

Either setting will prevent ant from spawning a new process for javac compilation.

ParserUtils picks up parser from web app (ID 6412405)

When accessing a JSP, the following exception may be logged under certain circumstances:


java.lang.AbstractMethodError: org.apache.xerces.dom.DeferredDocumentImpl.
setDocumentURI(Ljava/lang/String;)V

Solution

Add the following system property to your domain.xml file:


<jvm-options>-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces. \
internal.jaxp.DocumentBuilderFactoryImpl</jvm-options>

Alternatively, remove the JAR file containing the org.apache.xerces package form your Web application's WEB-INF/lib.

TLDs in EAR-bundled JARs not found. (Glassfish Issue 590)

JAR-packed JSP tag libraries bundled in EAR files cannot be referenced by the JSP pages of a WAR file that is part of the EAR, even if the META-INF/MANIFEST.MF resources of that WAR file lists the tag library JAR file(s) in its Class-Path manifest attribute.

When accessing a JSP page that imports a tag library packaged in one the EAR file's JAR files, an error message similar to the following will appear in the server log and the JSP page will fail to compile:


The absolute uri: <taglib_uri> cannot be resolved in either web.xml or 
the jar files deployed with this application

Solution

Bundle any JSP tag library JAR files in the WEB-INF/lib directory of any WAR file whose JSP pages import those tag libraries.

More information about this bug can be found on the Glassfish site at https://glassfish.dev.java.net/issues/show_bug.cgi?id=590.

Platform-specific Issues

Must use fully qualified domain names when setting denyRemoteHost and allowRemoteHost properties on Windows XP and Windows Server 2003 (ID 6377272)

On Windows systems, you must use fully qualified domain names (for example, myhost.mydomain.com) instead of the short name (for example, just myhost) for Windows hosts in setting IP-based request filtering properties, even though Windows commands such as hostname and ipconfig /all and Java the API InetAddress.getLocalHost().getHostName() return short host names.

For example, the following command denies access by Windows host foobar:

asadmin --user adminuser --password adminpasswd 
--echo server.http-service.virtual-server.server.property.denyRemoteHost=foobar.sun.com

Note that the host name is fully-qualified with the DNS domain name, foobar.sun.com.