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:
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.
Do one of the following:
Leave domain1 intact, and create your other domains around it.
Remove domain1 and replace the hard-coded value for domain1 in $INSTALL/lib/package-appclient.xml with the new domain name. This will have to be done every time a new domain is created if domain1 is not present.
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.
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.
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. |
Use the Admin Console GUI to display error statistics. This issue will be fixed in a later release.
This section describes known application client issues and associated solutions.
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.
None at this time.
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% |
Remove the double quotes that surround the references to APPCPATH (and JAXP_IMPL_JARS).
This section describes known installation/uninstallation issues and associated solutions.
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.
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.
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.
To work around this issue:
Unset the JAVA_HOME variable by running unset or unsetenv depending on your shell.
Run setup with the -javahome option to specify the JAVA_HOME used by the installer.
This section describes known lifecycle management issues and associated solutions.
[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.
minimum-delivery-interval is the minimal interval duration between deliveries of the same periodic timer.
redelivery-interval-in-mills is the time the timer service will wait after a failed ejbTimeout before attempting redelivery.
The problem is that the logic that relates the redelivery interval property to the minimum delivery property is incorrect and prevents you from using the GUI or the CLI to set any value where the minimum delivery interval is greater than redelivery interval.
The minimum-delivery-interval-in-millis must always be set equal to or higher than ejb-timer-service property redelivery-interval-in-millis. The problem is that there is an erroneous validation check in the Application Server to verify that the value for redelivery-interval-in-millis is greater than the value for minimum-delivery-interval-in-millis.
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.
This section lists known issues and associated solutions related to the Java Persistence API.
See https://glassfish.dev.java.net/issues/show_bug.cgi?id=572 for more information.
Do not use this type of query.
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:
Type compatibility of function arguments.
Type compatibility of operands of arithmetic, logical, and comparison operators
SELECT clause requirements for an ORDER BY query.
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.
Verify the above conditions manually.
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 |
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 |
For more information, see https://glassfish.dev.java.net/issues/show_bug.cgi?id=550.
Manually verify what is wrong in the query.
Use different class names.
For more information, see https://glassfish.dev.java.net/issues/show_bug.cgi?id=558.
Do not list MappedSuperclass explicitly.
For more information, see https://glassfish.dev.java.net/issues/show_bug.cgi?id=578.
Do not use ManyToMany relationship in a subclass.
For more information, see https://glassfish.dev.java.net/issues/show_bug.cgi?id=557.
Use java.util.Collection instead.
Use Java wrapper types for mapping to nullable database columns.
For more information, see https://glassfish.dev.java.net/issues/show_bug.cgi?id=404.
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 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.
Select a state field from the related instance.
SELECT o.customer.customerId FROM Order o WHERE ... |
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.
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 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.
Use the class of the topmost superclass as the argument to the find() method, and cast the result to the subclass.
See https://glassfish.dev.java.net/issues/show_bug.cgi?id=643 for more information.
Use java.util.ArrayList as the initial value.
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.
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.
Instead of delegating to the “previous” VariableResolver to resolve an expression, we recommend creating an ValueExpression and evaluating it.
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; } }
This section describes known issues and associated solutions related to upgrading and using the Upgrade Tool.
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.
Before starting the upgrade process, copy all the domain directories from their different locations to the install_dir/domains directory.
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.
This issue is not encountered if command line installation mode is used to run upgrade in place.
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.
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.
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.
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.
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.
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.
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.
This section describes known web container issues and associated solutions.
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.
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.
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.
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)
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.
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 |
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.
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 |
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.
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.