Sun GlassFish Enterprise Server 2.1 Upgrade Guide

Correcting Potential Upgrade Problems

This section addresses the following issues that could occur during an upgrade to Enterprise Server:

Cluster Profile Security Setting

When you upgrade a cluster domain from Application Server 9.1/GlassFish v2 to Enterprise Server, you could encounter problems because the security setting is incorrect for the admin-service whose type attribute is das-and server in the target domain.xml. The solution is to edit the domain.xml file in the corresponding upgraded domain and correct the setting of the security-enabled attribute. Look for the following statements in the domain.xml file.

<admin-service system-jmx-connector-name="system" type="das-and-server">
<|-- The JSR 160 "system-jmx-connector"-->
<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="true">

Cluster Profile Upgrade on Windows

On Windows, when you upgrade cluster profile domains, you could encounter the following error:


Fatal error while backing up the domain directory

To resolve this error, look for and remove any hidden files in the source domain's directory and run Upgrade tool.

_TimerPool Resource

The datasource class used for a jdbc-connection-pool resource named __TimerPool has changed from org.apache.derby.jdbc.EmbeddedXADataSource in Application Server 8.x EE to org.apache.derby.jdbc.ClientDataSource in Application Server 9.1 Update 1. This change requires a addition of two property elements, User and Password to the jdbc-connection-pool element in the domain.xml file. Edit the Application Server 9.1 Update 1 domain.xml file and add the appropriate user name and password. Example:

<property name="User" value="APP"/> <property name="Password" value="APP"/>

Missing Client JAR Files

You have deployed applications that use client JARs in Application Server 8.x. You upgrade your existing installation to Enterprise Server. You could run into problems while trying to run these applications (that were deployed in Application Server 8.x) in Enterprise Server.

To solve this problem, perform the following steps:

  1. After upgrade, start Enterprise Server.

  2. Use the asadmin get-client-stubs command to transfer the missing client stubs to a local directory. See get-client-stubs(1).

  3. Run the appclient pointing to the client JAR files in the local directory.

Applications that Use JavaDB

You have deployed applications that use JavaDB databases in Application Server 8.x. You upgrade your existing installation toEnterprise Server. You run the asadmin start-database command and successfully start JavaDB. In this scenario, you could run into problems while trying to run these applications (that were deployed in Application Server 8.x) in Enterprise Server because the instance directory of JavaDB in Enterprise Server has changed.

To solve this problem, perform the following steps:

  1. After upgrade, start Enterprise Server.

  2. Use the asadmin start-database command with --dbhome option pointing to older (Application Server 8.x) version of JavaDB. Example asadmin start-database --dbhome /home/johnsmith/appserver8.2/databases

  3. Deploy the migrated applications.

classpath-prefix and classpath-suffix Not Transferred

Upgrade tool may fail to transfer java-config attributes, classpath-suffix, classpath-prefix, java-home, or server-classpath, because the information provided can be implementation-specific. Certain attributes may be partially transferred.

JVM Options That are Not Transferred

When you upgrade from a previous version of the application server, transfer of the previous configuration is required. Since the target configuration files may have new parameters and new preconfigured features, copying the old configuration files to the new server installation is not possible. The values of the old configurations must be transferred to the Enterprise Server configuration format.

The following JVM options are not transferred from the source to the target installation:

The options that are not transferred are listed down in the upgrade log. The user can manually change such attributes in the configuration file.

Port Conflicts

After upgrading the source server to Enterprise Server, start the domain and then the node agent, which, by default, starts the server instances. If you have upgraded from Application Server 8.x EE, you might face problems while attempting to start the node agent. The domain, clusters, and instances have admin port set to 4849 and the node agent points to 4848. You need to manually modify the admin port to which the node agent points. To change the node agent port, edit the agent.das.port property in the install_dir/nodeagents/node-agent-name/server_name/config/das.properties file.

Start the Admin Console and verify that these servers are started. If any of the servers are not running, in the install_dir/nodeagents/node-agent-name/server_name/logs/server.log file, check for failures that are caused by port conflicts. If there any failures due to port conflicts, use the Admin Console and modify the port numbers so there are no more conflicts. Stop and restart the node agent and servers.


Note –

The default ports in Enterprise Server are:


Single Domain with Multiple Certificate Database Passwords

If the upgrade includes certificates, provide the passwords for the source PKCS12 file and the target JKS keyfile for each domain that contains certificates to be migrated. Since Application Server 8uses a different certificate store format (NSS) than that of Application Server 8 PE (JSSE), the migration keys and certificates are converted to the new format. Only one certificate database password per domain is supported. If multiple certificate database passwords are used in a single domain, make all of the passwords the same before starting the upgrade. Reset the passwords after the upgrade has been completed.

Load balancer Plug-in Problems During Side-by-Side Upgrade

While upgrading from Application Server 8.x EE to Enterprise Server, during a side-by-side upgrade, you will not be able to point your new load balancer plug-in to the old 8.x web server installation, if the load balancer plug-in is colocated with other Application server components on a single system. You need to install web server again and point the older load balancer plug-in installation to the instance belonging to the new installation.

ProcedureAdditional HTTP Listeners

If additional HTTP listeners have been defined in the source server, those listeners need to be added to the target server after the upgrade:

  1. Start the Admin Console.

  2. Expand Configuration.

  3. Expand HTTP Service.

  4. Expand Virtual Servers.

  5. Select <server>.

  6. In the right hand pane, add the additional HTTP listener name to the HTTP Listeners field.

  7. Click Save when done.

ProcedureAdditional HTTP and IIOP Listeners

If additional HTTP listeners or IIOP listeners have been defined in the source server, the IIOP ports must be manually updated for the target EE servers before any clustered instances are started. For example, MyHttpListener was defined as an additional HTTP listener in server1, which is part of the cluster. The other instances in the cluster also have the same HTTP listener, because server instances are symmetrical in a cluster. In the target configuration named <cluster_name>-config, this listener must be added with its port set to a system property, {myHttpListener_HTTP_LISTENER_PORT}. In the target server, each server instance in this cluster that uses this configuration would have system property named myHttpListener_HTTP_LISTENER_PORT. The value of this property for all server instances is set to the port value in the source server, server1. These system properties for these server instances must be manually updated with nonconflicting port numbers before the server is started.

If additional HTTP listeners have been defined in the source server, those listeners need to be added to the target server after the upgrade:

  1. Start the Admin Console.

  2. Expand Configuration and select the appropriate <server>-config configuration.

  3. Expand HTTP Service.

  4. Expand Virtual Servers.

  5. Select <server>.

  6. In the right hand pane, add the additional HTTP listener name(s) to the HTTP Listeners field.

  7. Click Save when done.