1. GlassFish Server Upgrade Compatibility Issues
2. Upgrading an Installation of Application Server or GlassFish Server
Summary of Upgrade Tools and Procedures
Summary of Tools for Performing an Upgrade
Update Tool and the pkg Utility
Summary of Procedure for Upgrading With Upgrade Tool
Summary of Procedure for Upgrading With Update Tool
Summary of Procedure for Upgrading With the Software Update Notifier
Summary of Procedure for Upgrading With the pkg Utility
Supported Releases for Upgrade to GlassFish Server 3.1
Upgrading From Version 8.x or Older Product Releases
Upgrading GlassFish Server Inside a Closed Network
Performing a Side-By-Side Upgrade With Upgrade Tool
Migration of Deployed Applications
To Upgrade From the Command Line Using Upgrade Tool
To Upgrade Using the Upgrade Tool Wizard
Performing an In-Place Upgrade With the Update Center Tools
To Upgrade Using the Update Tool GUI
To Upgrade Using the Software Update Notifier
To Upgrade From the Command Line Using the pkg Utility
Upgrading Installations That Use NSS Cryptographic Tokens
To Perform Post-Upgrade Configuration
To Upgrade PKCS#11 Hardware Tokens
Upgrading Clusters and Node Agent Configurations
Overview of Cluster and Node Agent Upgrade Procedures
Correcting Potential Upgrade Problems
Cluster Profile Security Setting
Cluster Profile Upgrade on Windows
This section explains additional steps you need to perform when upgrading cluster and node agent configurations from Application Server or Enterprise Server to GlassFish Server 3.1.
GlassFish Server 3.1 does not support node agents. As part of the upgrade process, any node agent elements in the older source configuration are transformed into CONFIG node elements in the domain.xml file for the upgraded DAS. If the source node agent configuration is incompatible with your GlassFish Server 3.1 installation, you must correct the node configuration on the upgraded DAS.
In addition, although the source cluster configuration is retained in the domain.xml file for the upgraded DAS, it is still necessary to install GlassFish Server 3.1 on each node host and manually re-create the server instances that are contained in the clusters.
The following topics are addressed here:
The general steps for upgrading a cluster and node agent configuration so it will work in GlassFish Server 3.1 are as follows:
Perform a side-by-side upgrade of the DAS. This procedure is described in Performing a Side-By-Side Upgrade With Upgrade Tool.
Perform new (not upgrade) GlassFish Server 3.1 installations on each node host. GlassFish Server 3.1 installation instructions are provided in the Oracle GlassFish Server 3.1 Installation Guide.
Correct the node configuration on the upgraded DAS, if necessary. This procedure is described in To Correct the Configuration of a Node After an Upgrade.
Re-create the clusters and server instances on each GlassFish Server 3.1 node host. This procedure is described in To Re-Create a Cluster.
As part of the upgrade process, node agent elements in the DAS configuration are transformed into GlassFish Server node elements of type CONFIG. This transformation does not affect the node agent directories for GlassFish Server instances. To create the equivalent directories for GlassFish Server instances after an upgrade, you must re-create the instances as explained in To Re-Create a Cluster.
The name of an upgraded node is the name of the node agent from which the node is transformed.
The host that the node represents is obtained from the configuration of the original node agent or, if not specified, is not set. If the configuration of the original node agent did not specify the name of the node host, you must update the node to specify the host that the node represents.
Default values are applied to the remainder of the node's configuration data.
The default values of the following items in a node's configuration data might not meet your requirements for the upgraded installation of GlassFish Server:
The parent of the base installation directory of the GlassFish Server software on the host, for example, /export/glassfish3.
The default is the parent of the default base installation directory of the GlassFish Server 3.1 software on the DAS host. If the GlassFish Server software is installed under a different directory on the node host, you must update the node's configuration to specify the correct directory.
The directory that will contain the GlassFish Server instances that are to reside on the node.
The default is as-install/nodes, where as-install is the base installation directory of the GlassFish Server software on the host. If you require the instances to be contained in a different directory, you must update the node's configuration to specify that directory.
If you are using secure shell (SSH) for centralized administration, you must also change the type of the node to SSH to enable the node for remote communication.
For more information about GlassFish Server nodes, see Chapter 3, Administering GlassFish Server Nodes, in Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide.
Before You Begin
Ensure that the following prerequisites are met:
A side-by-side upgrade on the DAS has been performed. For more information, see Performing a Side-By-Side Upgrade With Upgrade Tool.
If you are changing the type of the node to SSH, ensure that SSH is configured on the host where the DAS is running and on the host that the node represents. For more information, see Chapter 2, Setting Up SSH for Centralized Administration, in Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide.
If you are upgrading from an Enterprise Profile configuration that uses NSS authentication, ensure that the procedure in Upgrading Installations That Use NSS Cryptographic Tokens has been performed. GlassFish Server 3.1 does not support NSS authentication.
Remote subcommands require a running server.
Note - Only the options that are required to complete this task are provided in this step. For information about all the options for changing the node's configuration data, see the update-node-ssh(1) help page or the update-node-config(1) help page.
asadmin> node-update-subcommand [--installdir install-dir] [--nodedir node-dir] [--nodehost node-host] node-name
The subcommand to run to update the node.
If you are leaving the type of the node as CONFIG, run the update-node-config subcommand on the node.
If you are changing the type of the node to SSH, run the update-node-ssh subcommand on the node.
The full path to the parent of the base installation directory of the GlassFish Server software on the host, for example, /export/glassfish3.
The path to the directory that will contain GlassFish Server instances that are to reside on the node. If a relative path is specified, the path is relative to the as-install directory.
The name of the host that the node is to represent after the node is updated.
The name of the node to update. This name is the name of the node agent from which the node was transformed.
Example 2-2 Correcting the Configuration of a Node After an Upgrade
This example updates the path to the directory that will contain instances that are to reside on the node xk01 to /export/home/gf/nodes. Because this node is transformed from a node agent, the type of the node is CONFIG. Therefore, type of the node is not changed.
asadmin> update-node-config --nodedir /export/home/gf/nodes xk01 Command update-node-config executed successfully.
Next Steps
Re-create the cluster configuration from the older source installation in the new GlassFish Server 3.1 installation in as explained in To Re-Create a Cluster.
See Also
This procedure explains how to re-create a clustered GlassFish Server or Enterprise Server configuration for GlassFish Server 3.1.
Before You Begin
Before proceeding with these instructions, ensure that you have completed the following procedures:
Perform the standard upgrade to GlassFish Server 3.1 on the DAS, as described in Performing a Side-By-Side Upgrade With Upgrade Tool.
Perform a new (not upgrade) installation of GlassFish Server 3.1 on each node host. See Oracle GlassFish Server 3.1 Installation Guide for instructions.
Correct the upgraded node configuration, if necessary, as described To Correct the Configuration of a Node After an Upgrade.
asadmin> start-domain domain-name
If the upgrade succeeded, the migrated cluster configuration exists and the get-health subcommand lists the status of the clustered instances as not running.
asadmin> get-health cluster-name
For example, for the sample cluster1 used in this procedure:
asadmin> get-health cluster1 instance1 not started instance2 not started Command get-health executed successfully.
The specific commands to use depend on your configuration.
Note that the node name matches that used for the node agent in the 2.x installation. If you get an error stating that some attributes do not match the values in the DAS configuration, follow the instructions in To Correct the Configuration of a Node After an Upgrade.
For example:
asadmin> start-cluster cluster1
This step may or may not be necessary, depending on the procedure you used to create the server instances for the cluster.
Example 2-3 Creating Two Local Instances
The following example shows how to create two local instances in a cluster.
host1$ asadmin --host dashost create-local-instance --node na1 --cluster cluster1 instance1 host2$ asadmin --host dashost create-local-instance --node na2 --cluster cluster1 instance2
The name of the DAS host.
The name of the node host.
The name of the cluster.
The names of the instances.