This section describes known Upgrade utility issues and associated solutions.
Domains created in custom-path other than as-install/domains directory are not upgraded directly while upgrading from Application Server Enterprise Edition 8 to Application Server Enterprise Edition 8.1.
When running the Upgrade Utility and identifying the as-install as the source installation directory, the upgrade process upgrades only those domains that are created under as-install/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 as-install/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 Red Hat 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:
as-install/bin/asupgrade --source as-install/domains --target as-install --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://as-install/docs-ee/about.html |
If you also selected the installation option to register the product, follow the link to registration page available on product About page.
Remove the following entries from the target domain.xml (after the upgrade) and restart the server:
<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot} /config/keystore.jks</jvm-options>- <jvm-options>Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot} /config/cacerts.jks</jvm-options>
The upgrade tool overwrites any existing index.html file for any server instance.
Back up your existing index.html files before running the upgrade tool, and then restore those files later.
When upgrading from Application Server 8.0PE to 9.1, an error is thrown saying the server does not have system connector named null, and invalid user information as seen in sbs-manual. Even after changing the hardcoded values, the same error message is seen. This occurs because the domain.xml has changed between 8.0 and 9.1.
You can only encounter this bug while upgrading from a 8.0 PE to 9.1. The workaround is to upgrade to either 8.1, 8.2, or 9.0 and then upgrade to 9.1.
When performing an inplace upgrade, in cases where there are multiple domains in the source, the installer invokes upgrade tool even though the process is killed. This happens when it is invoked in GUI mode.
Install inplace in the CLI mode, and exit when the installer prompts you to select the upgrade tool at the end of installation process. This does not delete any of the domains present in the domains directory. Upgrade tool should be manually invoked from the bin directory.
When installing inplace in GUI mode, make a backup of the domains present in the domains root to prevent losing any domains in the process. At the end of the installation process, exit when the installer prompts you to invoke the upgrade tool. Copy any backed up domains into the domains directory if they have been lost. Launch upgrade tool manually to do an upgrade.
When upgrading from AS 8.2 to 9.1, the master password from the 8.2 installation is not inherited in the 9.1 installation. This subsequently causes an authentication error at the next admin login.
The default admin password in Application Server 9.1 is changeit. To avoid problems when logging in to the 9.1 server after upgrading from 8.2, do one of the three following things:
Change the 8.2 admin password to changeit before performing the upgrade.
Do not accept the default admin password during the upgrade process, but instead explicitly enter the password you want to use.
Log in to 9.1 with the default password, and then immediately change it.
The upgrade tool does not deal with upgrading databases or database tables in any form, nor will it ever support this. The resource references configurations are transferred and the Application Server should continue to work with the original database and tables. If you want to change the database or transfer database tables, use the tools that work with the databases in use.
Perform the following steps to migrate the MQ store:
Perform the following steps AFTER AS 8.2 has been shut down and AFTER the AS9.1 upgrade tool is run but BEFORE AS9.1 is started for the FIRST time. If you have already started AS 9.1 after the IFR install/upgrade, then DO NOT perform these steps as they will potentially destabilize the MQ message store.
Copy the entire domain-dir/imq subdirectory from the AS 8.x domains directory to the AS 9.1 domains directory.
Ensure that the ownership of the directory and files is the same as the user that is going to be running the Application Server.
After performing the above steps, Application Server 9.1 can be started and the MQ store in the Application Server 9.1. domains directory will be migrated from its JES5 U1 format to MQ 4.1 format. Note that the original JES5 U1 MQ store under AS 8.2 is preserved and unmodified by this procedure or by MQ4.1 upon startup by AS 9.1
When upgrading from JES5 (Application Server 8.2) to Application Server 9.1, the Portal Server Community sample no longer works, and throws many javax.faces.application.ApplicationFactory errors.
Upgrading from Application Server 8.2 to 9.1 is not supported if Application Server 8.2 was installed with the JES5 Portal Server. Portal Server needs to be upgraded to Java ES 5 Update 1 prior the Application Server upgrade to 9.1.
When upgrading from Application Server 8.2 to 9.1 with the IFR installer on Linux platforms, selecting the Install JDK option, but after successful completion of the installation, most of the JES components stop working.
This issue only affects IFR installation of Application Server 9.1 in Linux platforms, and only when the Install JDK option is selected. To work around this issue, immediately after installation manually link /usr/jdk/entsys-j2se to the /usr/java/jdk1.5.0_12 directory.
When performing an Application Server 9.1 IFR upgrade on Windows, in-place backup is not correctly integrated with asupdate.bat form values. Specifically, if you enter incorrect information in an ASupdate.bat GUI screen and then click Next, the upgrade installer tries to detect if it is an in-place upgrade. If yes, domain1 is moved to a backup directory prior upgrade. As the upgrade proceeds, and an error message is displayed as a result of the incorrect information. When you attempt to correct the error right away, the a path error is thrown because domain1 was already moved.
Either change the source directory to be the domain1_timestamp directory in current-source-path/backup or exit the installer with the Cancel button and start again.
(Windows only) If an earlier version of Application Server was installed using special characters or DOS-style short names in the program directory path, subsequent in-place upgrades to Application Server 9.1 will fail if those same directory path names are used.
For example, if Application Server 8.2 was installed in either:
C:\Program Files (x86)\dirs\appserver c:\progra~2\dirs\appserver |
Attempts to perform an in-place upgrade to 9.1 will fail because the installer cannot convert the short names or special characters to the required long name format.
Installing Application Server using a path name that contains special characters or the DOS-style short name truncation (such as progra~2) is strongly discouraged because it impedes subsequent upgrade installations. If such an installation exists, either reinstall it using long path names before upgrading, or install the new version of Application Server in an entirely new directory.
After an Application Server upgrade, the <jsp:forward> tag does not work as expected in Authenticate.jsp. The <jsp:forward> call produces an error in the server logs and a blank page is shown on the WebUI. The problem is that <jsp:forward> in Authenticate.jsp requires a page attribute like <jsp:forward page="${redirectPage}"/>, but the value being passed is a relative path like /registry/thin/{pagename}.jsp, which does not work even Authenticate.jsp is a pure JSP page.
After completing the Application Server upgrade, use the asadmin tool to run the following commands to set the <auth-realm> in domain.xml:
Go to as-install/bin and run the following command:
./asadmin delete-auth-realm --host localhost --port 6489 certificate |
This removes the old auth-realm certificate, if one exists.
Run the following command:
./asadmin create-auth-realm --terse=false --echo=true --interactive=true \ --user admin --host localhost --port 6489 --classname \ com.sun.enterprise.security.auth.realm.certificate.CertificateRealm \ --property assign-groups=have.client.cert certificate |
This creates the new <auth-realm> with the assign-groups property.
Stop and restart the Application Server registry domain.
When running the asupgrade GUI in a language other than English, the online help for the GUI is not localized for the selected non-English language.
None at the time. Online help is scheduled to be localized in all non-English target languages.
After a side-by-side upgrade of a configuration that contains multiple domains, only the node agents of the last processed domain are present. This issue occurs because Upgrade Tool removes and re-creates the nodeagents directory in the target each time Upgrade Tool processes a domain.