This section describes known installation 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 Linux Red Hat 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:
If you also selected the installation option to register the product, follow the link to registration page available on product About page.
On Windows, immediately after installing Application Server Enterprise Edition, the Message Queue broker fails on startup with a message saying the directory drive:\as\domains\domain1\imq does not exist.
Note that if the broker is started after starting domain1, the directory will be created by the Application Server and the problem will not occur.
Create the var_home_dir_location before creating the broker:
$imqbrokerd -varhome var_home_dir_location
$imqbrokerd -varhome D:\as\domains\domain1\imq
When installing the bundled SDK on Windows Vista, you may encounter the error “Unsupported Installation Platform Detected.” However, the installation succeeds without any issues.
This is not really a problem. Application Server runs on Windows Vista, and this erroneous message will be removed in future versions of the product.
If the Application Server productregistry file contains shared component configurations, an Application Server uninstallation procedure does not update the productregistry file correctly, and you will not be able to use silent mode in a subsequent installation unless the productregistry file is renamed or removed. Leaving the shared components entries in the productregistry file intact is by design, but it leads to confusion with subsequent silent installs.
After a successful uninstallation is reported back through uninstall log files, delete the productregistry file prior to running a subsequent installation. To verify that a previous uninstallation has completed successfully, look for a appserv_uninstall.class file in as-install. This file will not be present if the uninstallation was successful.
Do not delete the productregistry if the uninstallation was not successful.
The productregistry file is located in /var/sadm/install on Solaris and /var/tmp on Linux.
When installing Application Server in a sparse local zone, the installation fails if Message Queue (MQ) is not installed first. The installer attempts to install MQ, and then the whole installation fails.
MQ must be manually installed in the global zone before installing Application Server in a sparse local zone. There are two work-arounds for this issue:
Install MQ 4.1 manually in the global zone from the same media on which Application Server 9.1 IFR installation is located to get the latest MQ packages.
Use the installer that corresponds to your platform:
mq4_1-installer-SunOS.zip mq4_1-installer-SunOS_X86.zip mq4_1-installer-Linux_X86.zip mq4_1-installer-WINNT.zip
Unzip the bits and run the installer.
The installer will be in the mq4_1-installer directory.
Install any component of IFR installation in global zone. This action would check the version of MQ in GZ and if required upgrade it to the one bundled in Application Server 9.1 IFR. Even Selecting and Installing the Sample Applications component upgrades MQ to IFR version.
Run the Application Server installation in the global zone, but select only the sample components.
The sample component installation also installs MQ and Application Server shared components in all zones.
Run the Application Server installation again, this time in the local sparse zone.
Installation should complete without any problems.
When running the Application Server 9.1 IFR installer with the —console option (command-line mode), you are prompted:
Do you want to upgrade from previous Application Server version?
Unfortunately, the IFR installer does not support such upgrades, and so this prompt is erroneous. If you answer yes to the prompt, the installation proceeds normally, but no indication that a complete installation was performed, rather than an upgrade.
Use the upgrade tool if you want to upgrade your Application Server installation.
The following exceptions might be thrown:
#|2008-11-19T01:44:37.422+0530|SEVERE|sun-appserver9.1|org.apache.catalina.session.ManagerBase|_ThreadID=17;_ThreadName=pool-1-thread-3;_Req uestID=cc0ddf54-a42e-400a-9788-e30d79a25d88;|PWC2768: IOException while loading persisted sessions: java.io.InvalidClassException: org.apache .catalina.session.StandardSession; local class incompatible: stream classdesc serialVersionUID = 8647852380089530442, local class serialVersi onUID = -8515037662877107054 java.io.InvalidClassException: org.apache.catalina.session.StandardSession; local class incompatible: stream classdesc serialVersionUID = 864 7852380089530442, local class serialVersionUID = -8515037662877107054..... .....
After upgrade is done and the upgrade domain is started, these exceptions can be ignored if they occur.
Installation fails on 64–bit systems that have 64–bit JDK because the installer tries to use the 64–bit JDK.
If you are installing Application Server on a 64–bit system, download the 32–bit JDK and use it to install Application Server on your 64–bit machine. You will need to use the following command:
./distribution_filename –javahome path-to–32bit-JDK-location
After installation, to ensure that Enterprise Server uses a 64–bit JDK, edit the value of the AS_JAVA variable in the asenv.conf file to point to the 64–bit JDK installation.