|
| |
| Sun Java Enterprise System 5 Update 1 Upgrade Guide for UNIX | |
Chapter 1
Planning for UpgradesThis chapter provides information used for planning the upgrade of Sun Java™ Enterprise System (Java ES) software to Java ES 5 Update 1 in a Sun Solaris™ Operating System or Red Hat Enterprise Linux (referred to simply as Linux) operating system environment.
It contains the following sections:
Java ES 5 Update 1 ComponentsAs an introduction to planning the upgrade of Java ES software, this section reviews the components included in Java ES 5 Update 1 (Release 5U1). Depending on your upgrade scenario, you might need to upgrade one or more of these components to their Release 5U1 version.
Java ES components are grouped into different types, as described in the Java Enterprise System 5 Update 1 Technical Overview, http://docs.sun.com/doc/820-2969:
Release 5U1 Product Components
Release 5U1 product components are listed alphabetically in the following table, along with abbreviations used in subsequent tables. For the service quality components among them, the table includes the type of service enhancement they provide.
Table 1-1 Java ES 5 Update 1 Product Components
Product Component
Abbreviation
Version
Type
Access Manager
AM
7.11
System service component
Application Server
AS
8.2 EE
Patch 2System service component
Directory Proxy Server
DPS
6.2
Service quality: access component
Directory Server
DS
6.2
System service component
High Availability Session Store
HADB
4.4.31
Service quality: availability component
Java DB
JavaDB
10.2.2.1
System service component
Message Queue
MQ
3.7 UR2
System service component
Monitoring Console
MC
1.0 Update 1
Service quality: administrative component
Portal Server
PS
7.1 Update 2
System service component
Portal Server Secure Remote Access
PSRA
7.1 Update 2
Service quality: access component
Service Registry
SR
3.1 Update 1
System service component
Sun Cluster
SC
3.1 8/051
Service quality: availability component
Sun Cluster Geographic Edition
SCG
2006Q41
Service quality: availability component
Web Proxy Server
WPS
4.0.5
Service quality: access component
Web Server
WS
7.0 Update 1
System service component
1This is the same version delivered with Java ES 5.
Release 5U1 Shared Components
Release 5U1 shared components are listed alphabetically in the following table, along with abbreviations used in subsequent tables.
Table 1-2 Java ES 5 Update 1 Shared Components
Shared Component
Version
Abbreviation
Apache Commons Logging
1.0.31
ACL
Jakarta ANT Java/XML-based build tool
1.6.51
ANT
Berkeley Database
4.2.521
BDB
Common Agent Container
1.1 and 2.1
CAC
FastInfoSet
1.0.21
FIS
International Components for Unicode
3.2 Patch 1
ICU
Instant Messenger SDK
6.2.81
IM-SDK
Java Platform, Standard Edition
5.0 Update 12
Java SE
JavaBeans™ Activation Framework
1.0.31
JAF
Java Studio Web Application Framework
2.1.51
JATO
JavaHelp™ runtime
2.01
JavaHelp
JavaMail™ runtime
1.3.21
JavaMail
Java Architecture for XML Binding runtime
2.0.31
JAXB
Java API for XML Processing
1.3.11
JAXP
Java API for XML Registries runtime
1.0.81
JAXR
Java API for XML-based Remote Procedure Call runtime
1.1.3_011
JAX-RPC
Java API for Web Services runtime
2.01
JAXWS
Java Calendar API
1.21
JCAPI
Java Dynamic Management™ Kit runtime
5.1_03
JDMK
Java Security Services (Network Security Services for Java)
4.2.5 and 3.1.11
JSS and
JSS3JavaServer Pages™ Standard Tag Library
1.0.61
JSTL
KT Search Engine
1.3.41
KTSE
LDAP C SDK
6.01
LDAP C SDK
LDAP Java SDK
4.191
LDAP J SDK
Mobile Access Core
6.21
MA Core
Netscape Portable Runtime
4.6.7
NSPR
Network Security Services
3.11.7
NSS
SOAP Runtime with Attachments API for Java
1.31
SAAJ
Simple Authentication and Security Layer
2.191
SASL
Sun Explorer Data Collector (Solaris only)
4.3.11
SEDC
Sun Java Monitoring Framework
2.0 Update 1
MFWK
Sun Java Web Console
3.0.3
SJWC
Web Services Common Library
2.01
WSCL
XML Web Services Security
2.01
XWSS
1This is the same version delivered with Java ES 5.
Upgrade Plan ConsiderationsAn upgrade plan is the essential starting point for performing an upgrade to Java ES 5 Update 1 (Release 5U1). In an upgrade plan you specify the Java ES components you will upgrade to Release 5U1 and the sequence by which you will upgrade those components on the different computers or operating system instances in your Java ES deployment.
Your upgrade plan depends on a number of factors, each of which should be given careful consideration in preparing for upgrade to Release 5U1:
Upgrade Objectives and Priorities
An upgrade plan reflects your upgrade objectives and priorities, which often depend on the scope and complexity of your existing deployment architecture.
For example, your Java ES deployment architecture might consist of a single Java ES component running on a single computer, and your upgrade objective is to fix some bug in the previous software release. On the other hand, your Java ES deployment architecture might consist of a number of interoperating Java ES components deployed across a number of different computers, and your upgrade objective is to achieve some new functionality by upgrading the minimum number of components required to achieve that end with minimal downtime.
In general, the greater the number of Java ES components and computers in your deployment architecture, and the more ambitious your upgrade objectives, the more complex will be your upgrade plan.
The Java ES Release Model
A key consideration in planning an upgrade is whether the objective of the upgrade is to achieve major functional enhancements or to apply bug fixes (or minor functional updates) to existing software.
The Java ES release model is a categorization scheme for Java ES releases that clarifies the nature of the releases, their relationships to one another, and the risks and planning required to upgrade from one to another.
Component Release Levels
The Java ES release model is based on a set of release levels that define the characteristics of individual Java ES component releases:
- Major release. The purpose of a major release is to introduce or change significant software functionality and architectural features. As such, it can introduce incompatibilities with previous versions, and operating system support may be dropped. As a result, users may be required to take specific actions in order for their applications to integrate with a major release. As part of upgrading to a new major release, users might have to perform migrations, redeployments, and possibly redesign their solutions to utilize new features or respond to the removal of old features.
- Minor release. The purpose of a minor release is to introduce new, non-interfering features without introducing incompatibilities. New prerequisites or dependencies can be established and previous features can be deprecated in a minor release. As compared to upgrading to a major release, users might have to perform migrations and redeployments, but a redesign of their existing solution should not be necessary.
- Update release. The purpose of an update release is to provide fixes to an existing component implementation so that it more accurately implements a prior release's functional specification. The update release provides for the delivery of bug fixes and a constrained set of feature enhancements such that the release remains suitable for adoption by the majority of existing users. When compared to a major or minor release an update release contains fewer, smaller and/or lower risk features. Other than in rare exceptions, an update release is 100% backwardly compatible with the prior release. Upgrading to an update release from the prior release should require minimal planning and investment.
- Point-fix release. The purpose of a point-fix release is to address critical customer issues quickly. Like an update release, it supports existing users, but is generally more limited or focused, typically containing only a few bug fixes. Feature enhancements or new feature additions are not allowed in a point-fix release. Upgrading to a point-fix release from the prior release should be simple an low risk.
Java ES System Release Types
A Java ES release is a consolidation of individual Java ES component releases that are synchronized and collected in a single distribution that can be used for initial installation and upgrade.
The Java ES release model specifies two general types of Java ES releases: feature releases, which can include all levels of component releases, including major and minor releases, and maintenance releases, which can include only update and point-fix releases.
The two types of Java ES releases have the characteristics described below:
- Feature release. The primary purpose of a feature release is to deliver new features and functional capabilities. While specific components within a Java ES feature release might be only update or point-fix releases, the purpose of the release is to deliver major or minor component releases. A Java ES feature release has the following general characteristics:
- The release can introduce significant interface changes, new dependencies, and/or incompatibilities with respect to Java ES components
- The release requires a longer planning cycle prior to adoption
- Upgrade to the release (a feature upgrade) generally requires reconfiguration and/or migration of component data
- The release can involve significant impact or risk
- Maintenance release. The primary purpose of a maintenance release is to fix bugs in the software, so that components work as originally documented. New features are limited in number and highly constrained. A Java ES maintenance release cannot include major or minor component releases, only update and point-fix releases. A Java ES maintenance release has the following general characteristics:
- The release cannot introduce significant interface changes, new dependencies, or incompatibilities with respect to Java ES components
- The release allows for quick adoption
- Upgrade to the release (a maintenance upgrade) requires no reconfiguration or migration of component data
- The release involves minimal impact or risk
Java ES Release Families
A Java ES release family consists of a feature release and its associated maintenance releases as illustrated in the following figure.
Figure 1-1 Java ES Release Family
A Java ES feature release initiates a release family, and a number of subsequent maintenance releases (called Java ES update releases) provide distributions that periodically consolidate intervening component update and point-fix releases. These individual component maintenance releases are independently collected in a Java ES accumulated patch cluster.
The maintenance aspect of the Java ES release model is represented by both the Java ES update release and the Java ES accumulated patch cluster, described as follows:
The accumulated patch cluster is established at the onset of a release family and has a life cycle corresponding to the support life of the release family. It is updated whenever a new component point fix or update release is made available. Other than in rare exceptions, the accumulated patch cluster is 100% backwardly compatible with earlier releases in its release family.
The significance of the Java ES release model shown in Figure 1-1, from an upgrade point of view, is that an upgrade from one Java ES release family to another (a feature upgrade) involves significant impact and risk, and requires a more complex upgrade plan, as compared to an upgrade within a release family (a maintenance upgrade). The approaches used to perform feature upgrades and maintenance upgrades are discussed in Java ES Upgrade Technologies.
Release Delivery Formats
The following table shows the delivery formats of the releases within the Java ES release model shown in Figure 1-1.
Supported Upgrade Paths and Strategies
Your upgrade plan depends on the Java ES release from which you wish to upgrade to Java ES 5 Update 1 (Release 5U1).
While it is possible to upgrade all previous releases of Java ES software to Release 5U1, the only supported upgrades are from Java ES 5 (Release 5U1), Java ES 2005Q4 (Release 4), Java ES 2005Q1 (Release 3), and Java ES 2004Q2 (Release 2). While this Upgrade Guide provides strategies for upgrading from Java ES 2003Q4 (Release 1) and releases that pre-date Java ES, it does not provide procedures for performing such upgrades.
The following table describes the different upgrade paths to Release 5U1, their characteristics, and the upgrade strategies to be used in performing the upgrade.
Because of the differences between upgrade paths described in the table, and because product component upgrade procedures often depend on which release is being upgraded, the chapters in this Upgrade Guide that describe the upgrade of each Java ES product component are divided into sections: each representing a different upgrade path.
Table 1-4 Upgrade Paths to Java ES 5 Update 1 (Release 5U1)
Product Version
Java ES Release
System Characteristics
Upgrade Strategies
Java ES 5
Release 5
Java ES 5 Update 1 (Release 5U1) supports a mixture of Release 5 and Release 5U1 product components and shared components on a single computer. Interoperability between Release 5 and Release 5U1 components is guaranteed.
Maintenance upgrade. The coexistence of Release 5 and Release 5U1 components provides for the possibility of selectively upgrading Release 5 components to Release 5U1 on a single computer or within a deployment architecture consisting of multiple computers.
However, if any Release 5U1 product component requires support of a Release 5U1 shared component, it is recommended that all shared components on the computer be synchronized to Release 5U1.
2005Q4
Release 4
Java ES 5 Update 1 (Release 5U1) supports a mixture of Release 4, Release 5, and Release 5U1 product components on a single computer, but requires that shared components be synchronized to the same release. Interoperability between Release 4 and Release 5 family components has been tested, and known interface incompatibilities are noted in the Java Enterprise System 5 Update 1 Release Notes, http://docs.sun.com/doc/819-4893.
Feature upgrade. The coexistence of Release 4 and Release 5U1 product components provides for the possibility of selectively upgrading Release 4 product components to Release 5U1 on a single computer or within a deployment architecture consisting of multiple computers.
If any Release 5U1 product component requires support of a Release 5U1 shared component, all shared components on the computer must be synchronized to Release 5U1.
2005Q1
Release 3
Similar to the Release 4 upgrade path, above. Java ES 5 Update 1 (Release 5U1) supports a mixture of Release 3, Release 4, Release 5, and Release 5U1 product components on a single computer, but requires that shared components be synonymized to the same release. Interoperability between Release 3 and Release 5 family components has been tested, and known interface incompatibilities are noted in the Java Enterprise System 5 Update 1 Release Notes, http://docs.sun.com/doc/819-4893.
Feature upgrade. Similar to the Release 4 upgrade path, above. The coexistence of Release 3, Release 4, Release 5, and Release 5U1 components provides for the possibility of selectively upgrading Release 3 components to Release 5U1 on a single computer or within a deployment architecture consisting of multiple computers.
If any Release 5U1 product component requires support of a Release 5U1 shared component, all shared components on the computer must be synchronized to Release 5U1.
2004Q2
Release 2
Contrasts with the Release 4 and Release 3 upgrade paths, above. Java ES 5 Update 1 (Release 5U1) does not support a mixture of Release 2 and Release 5U1 components, neither product components nor shared components, on a single computer. Known interface incompatibilities exist between the release versions, and interoperability between Release 2 and Release 5U1 components is not certified (has not been tested).
Feature upgrade. When upgrading components from Release 2 to Release 5U1 on a single computer, all Release 2 components must be upgraded to Release 5U1. However, it is sometimes possible to mix Release 2 and Release 5U1 components residing on different computers within a deployment architecture.
Java ES certifies indirect upgrade from Release 2 to Release 5U1 (upgrade from Release 2 to Release 5 followed by upgrade from Release 5 to Release 5U1). While Java ES does not certify (has not tested) direct upgrade from Release 2 to Release 5U1 for all components, procedures for direct upgrade are nevertheless documented in this Upgrade Guide when supported for a particular component.
2003Q4
and prior versionsRelease 1 and pre-dating Java ES
Similar to the Release 2 upgrade path, above. Java ES 5 Update 1 (Release 5U1) does not support a mixture of Release 1 and Release 5U1 components, neither product components nor shared components, on a single computer. Known interface incompatibilities exist between the release versions, and interoperability between Release 1 or prior releases and Release 5U1 components is not certified (has not been tested).
Feature upgrade. Java ES does not certify the direct upgrade of Release 1 or prior releases to Release 5U1.
In some cases, however, you can perform an upgrade from Release 1 by upgrading first to Java ES Release 3, as documented in the Release 3 Java Enterprise System Upgrade and Migration Guide, http://docs.sun.com/doc/819-0062, and then upgrading from Release 3 to Release 5U1. In those cases, the upgrade roadmap for that component in this Upgrade Guide notes this possibility.
In other cases the upgrade from Release 1 to Release 5U1 can be performed in the same way as the upgrade from Release 2, Release 3, or Release 4 to Release 5U1, and in those cases, the upgrade roadmap for that component in this Upgrade Guide notes this possibility.
Upgrade Dependencies
One of the main issues in planning the upgrade of a Java ES product component is to understand that component's dependencies on other Java ES components, and whether other components need to be upgraded to support the upgrade of the dependent component.
There are two types of upgrade dependencies:
- Hard upgrade dependency. An upgrade of a product component requires you to upgrade a component upon which it depends. This requirement can be due to new functionality, new interfaces, or bug fixes needed by the dependent component. With a hard upgrade dependency, you cannot successfully upgrade and use the dependent component without first upgrading the component upon which it depends.
- Soft upgrade dependency. An upgrade of a product component does not require you to upgrade a component upon which it depends. With a soft upgrade dependency, you can successfully upgrade and use the dependent component without upgrading the component upon which it depends.
Upgrading a Java ES product component requires you to upgrade all the components upon which it has hard upgrade dependencies, but, with some exceptions noted in this book, allows you to not upgrade components upon which it has soft upgrade dependencies. When multiple interdependent components are involved in an upgrade, you have to upgrade a component if only one of the Java ES components being upgraded has a hard upgrade dependency on that particular component.
In a few special cases, due to incompatibilities that are introduced, upgrade of a component requires you to also upgrade a component that it supports. These special cases are noted in this book.
Selective Upgrade or Upgrade All
The distinction between hard and soft upgrade dependencies allows for the possibility in your upgrade plan of selectively upgrading Java ES product components within a deployed system. Selective upgrade applies to upgrading from Release 3, Release 4, and Release 5 to Release 5U1 on a single computer. Selective upgrade from Release 2 to Release 5U1 on a single computer is not supported.
In general, you have the choice of performing a selective upgrade or upgrading all Java ES product components on a computer:
- Selective Upgrade. In this approach you start with the Java ES product component you wish to upgrade to Release 5U1. You determine the hard upgrade dependencies for that component; those components also need to be upgraded. Repeat this process for each successive hard upgrade dependency until no further components need to be upgraded. This exercise specifies all Java ES product components that need to be upgraded.
- Upgrade All. In this approach you upgrade all deployed Java ES product components to Release 5U1. In some cases, due to the complexity of a deployment, it is not feasible for business reasons to upgrade an entire system at one time.
The two approaches to performing upgrades are compared in the following table.
Selective upgrade was also supported in Java ES Release 4. It is therefore possible to have both Release 3 product components and Release 4 product components coexisting on a computer, both of which can be selectively upgraded to Release 5U1.
Multi-Instance Upgrades
The sequence of upgrade procedures in an upgrade plan depends on how redundancy is being used in a deployment architecture. Multiple instances of a Java ES component can be used to achieve high availability, scalability, serviceability, or some combination of these service qualities. Three technologies make use of redundant components in Java ES deployment architectures: load balancing (Directory Proxy Server, Web Server, Web Proxy Server, Application Server, Access Manager, and Portal Server), high availability techniques (Sun Cluster and High Availability Session Store), and Directory Server replication.
In most cases where redundancy is involved, upgrades must be performed without incurring significant downtime. These rolling upgrades attempt to successively upgrade redundant instances of a component without compromising the service that they provide.
Redundant instances are usually deployed across multiple computers. For upgrade planning, you might need to isolate the upgrade of replicated components from other component upgrades in order to achieve minimal downtime. You perform all the pre-upgrade tasks for the replicated components on each computer before performing the rolling upgrade.
Each replication technology has configuration or reconfiguration procedures that might affect the overall sequence of Java ES component upgrades. For example, components that run in a Sun Cluster environment can require upgrading Sun Cluster before upgrading the components that are running in the Sun Cluster environment.
The chapters in this Upgrade Guide that describe the upgrade of each product component describe how to perform multi-instance upgrades for their respective components.
Operating System Considerations
A number of operating system considerations can impact your Java ES upgrade plan, as described below.
Required Operating System Patches
Successful upgrade of a Java ES product component can require you to first patch the operating system or otherwise update the operating system to the level required by the Java ES 5 Update 1 product component. However, rather than applying the specific patches or fixes needed in each case, it is preferable to bring the operating system to the level required by Java ES 5 Update 1 as a whole before performing upgrades of specific product components.
- Solaris platform. Operating system patches are available through the SunSolve web site as a patch cluster, a collection of operating system patches that can be collectively applied. The patch clusters required to support Java ES 5 Update 1 for Solaris 9 and 10 are available at http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
- Linux platform. Update releases are available at https://www.redhat.com/apps/download/. However, it is not necessary to update the Linux operating system before performing Java ES upgrades.
Dual Upgrades: Java ES and Operating System Software
Operating system and Java ES software can become misaligned when you attempt to upgrade either Java ES software or operating system software to a non-supported version. The relevant support matrix is shown in the following table.
If an upgrade of Java ES software or operating system software would result in a non-supported configuration, then you have to perform a dual upgrade: one in which both Java ES and the operating system are upgraded. The following situations can require a dual upgrade:
For example, Java ES 2004Q2 (Release 2) is supported on Solaris 8 and 9 operating systems and on Red Hat Enterprise Linux (RHEL) 2.1. If you wish to upgrade your operating system platform to Solaris 10 or RHEL 3.0, which are not supported by Java ES Release 2, you also need to upgrade your Java ES Release 2 to a Java ES release version that supports the upgraded platform. In this case, it would be preferable to upgrade to Java ES 5 Update 1 (Release 5U1).
For example, Java ES 2005Q1 (Release 3) and Java ES 2005Q4 (Release 4) are supported on Solaris 8 and RHEL 2.1. If you want to upgrade Java ES to Release 5U1, however, which is not supported on Solaris 8 or RHEL 2.1, you must upgrade your operating system to versions supported by Java ES 5 Update 1 (Release 5U1). In this case, it would be preferable to upgrade to Solaris 10 or RHEL 4.0.
In general, there are two approaches you can take to performing a dual upgrade:
- Fresh operating system installation. Install the new operating system followed by a fresh installation of Java ES 5 Update 1, including migration of earlier version product component data (such as configuration data, runtime data, customizations, and so forth). The operating system installation can be on a new system (or Solaris 10 zone) or it can wipe out the existing file system. In the latter case, component data must first be backed up and then restored after the operating system installation.
- In-place operating system upgrade. Perform an operating system upgrade, leaving the existing file system in place, followed by an upgrade of Java ES product components to Release 5U1. For this to work, the operating system upgrade must have no impact on upgrade of the installed Java ES product components, their data, and required shared components.
If dual upgrade is not supported for any Java ES product component, that is, if neither of these approaches work, then you have to re-install and freshly configure that component after performing an operating system install or upgrade.
The following table shows the dual upgrade approach supported by each of the Java ES product components.
Operating System Upgrades
In some cases, upgrading the Solaris operating system overwrites existing Java ES shared components with earlier versions. In those cases the correct Java ES versions can be restored by upgrading Message Queue, which is bundled with the Solaris operating system, to Release 5U1. Upgrading Message Queue will force the upgrade of all resident shared components as well.
Solaris 10 Multizone Environments
A number of issues are involved in installing and upgrading Java ES components in a multizone environment. For a description of the benefits and limitations of deploying Java ES in Solaris 10 zones, and recommended practices for upgrading Java ES components in a multizone environment, see Java ES 5 Update 1 Upgrade and Solaris 10 Zones.
The Upgrade ProcessThe Java ES upgrade process involves a number of phases, which are normally carried out first in a staging environment, before being executed in a production environment. The use of a staging environment allows you to test each phase as well as write scripts to be used by IT personnel for upgrading complex Java ES deployments.
When you have tested the upgrade process in a staging environment, and have confidence that the upgrade is working properly, you can reproduce the process in your production environment.
The process involves the phases shown in the following table and documented in this Upgrade Guide. The phases apply to individual component upgrades as well as to your Java ES deployment as a whole.
Java ES Upgrade TechnologiesNo single system utility upgrades all Java ES components.
In particular, the upgrade of Java ES product components to Release 5U1 is performed component-by-component, computer-by-computer, using component-specific upgrade procedures documented in this Upgrade Guide.
A product component upgrade can be either a feature upgrade or a maintenance upgrade:
- Feature upgrade. An upgrade from a previous release family. This is a functional upgrade that might not be compatible with the versions of the component in the previous release family. A feature upgrade requires a full Java ES distribution and can be a relatively complex procedure, involving reconfiguration or migration of component data (see Product Component Feature Upgrades).
- Maintenance upgrade. An upgrade from Release 5 or subsequent maintenance release within the Release 5 family. This is a bug-fix or minor feature upgrade that is fully compatible with the previous version of the component in the release family. A maintenance upgrade requires a discrete set of patches and should be a relatively simple procedure (see Product Component Maintenance Upgrades).
Java ES product components and shared component upgrades have different characteristics and employ somewhat different upgrade technologies, as described in the following sections:
Product Component Feature Upgrades
Feature upgrades of Java ES product components to Release 5U1 from previous release families involve two basic operations that mirror the initial installation and configuration of Java ES product components:
- Installation of software upgrades. Upgraded software enhances or fixes existing software or replaces existing software. Software installation can be achieved through the application of patches to existing software packages, the selective replacement of existing packages, the installation of new packages, or a full re-installation of component software.
- Reconfiguration. Reconfiguration encompasses any change in configuration data, user data, or dynamic application data needed to support the upgraded software. A change in data can be additional data, a change in data format (whether in property files or database schema), or a migration of data to a new location. Sometimes reconfiguration must be performed manually and sometimes it takes place automatically. In some cases, reconfiguration also requires redeployment of component software to a web container.
In addition, Java ES product component upgrades normally involve pre-upgrade tasks and, in some cases, post-upgrade procedures before the upgrade is operational.
Feature Upgrade Approaches
When performing a feature upgrade to Release 5U1 from a previous release family, the component-specific upgrade procedures used to install upgraded software and perform component reconfiguration include the following upgrade approaches:
Using the Upgrade Capability of the Java ES Installer
The Release 5U1 installer includes an upgrade capability that performs product component upgrade in a few special cases: Application Server, Message Queue, HADB, and Java DB. When the Java ES installer detects the previously installed release versions of these product components, it marks these components as "upgradable."
Before upgrading any of these components, the installer checks for current and previous versions of shared components. If the installer detects that a shared component required by the selected component is of a previous version or is missing, the installer upgrades all shared components currently installed and installs any missing shared components required by the selected component. In some cases (notably Application Server), the installer will also upgrade product components upon which the component being upgraded depends.
The installer removes the previous version packages, installs the Release 5U1 product component packages, and reconfigures, as needed, the product component being upgraded. (In the case of Application Server bundled with Solaris 9 operating system, however, the installer does not remove packages; see the section on upgrading Release 2 Application Server in the Java Enterprise System 5 Update 1 Upgrade Guide for UNIX, http://docs.sun.com/doc/819-6553:.).
If you are using the Solaris 10 operating system zones feature, special considerations apply. See Zone Support in the Java ES Installer.
Performing a Fresh Install of the Product Component
Some product components are upgraded by performing a fresh install of the components using the Java ES installer. First you remove the previous version's packages and then install Release 5U1 in the same path, or install Release 5U1 in a parallel path and leave the previous version intact.
In both cases you reconfigure the product components by migrating the previous version's configuration data to the new installation, by performing a new configuration, or by doing a combination of both. For some product components, a utility is provided for reconfiguring or migrating configuration data for that component.
Running a Component-Specific Upgrade Utility
Some product components provide an upgrade utility or script for automating the upgrade of the component to Release 5U1. The utility generally performs both the upgrade of software packages and any reconfiguration required as part of the upgrade. For those components deployed to a web container, the utility generally redeploys the upgraded component software to the web container.
Patching Existing Component Packages
For some product components, feature upgrades are performed by manually patching existing software packages. In most cases no reconfiguration or migration of component data is required. More information on patching is provided in Product Component Maintenance Upgrades.
Feature Upgrade Approach Used for Each Product Component
The upgrade approach used to perform a feature upgrade of each product component to Release 5U1 is shown in the following table:
Product Component Maintenance Upgrades
With some exceptions (such as Portal Server), maintenance upgrades of Java ES product components to Release 5U1 from Release 5 involve only the patching of Release 5 packages. Unlike feature upgrades from previous release families, no reconfiguration or migration of component data is required.
Note
Before applying Java ES patches, be sure that your operating system has been updated to the latest required version. See Required Operating System Patches.
Solaris and Linux Patch Technologies
While Solaris and Linux platforms employ similar technologies for managing installed software packages and tracking changes to those packages through a package registry, the differences in patching technologies between platforms impact Java ES upgrade procedures.
Solaris patches can patch one or more packages. The patchadd command saves a backup of the package being patched to facilitate the removal of the patch using the patchrm command. Patches are identified by a patch ID, which consists of a patch number followed by a revision number that is incremented as the patch is modified over time.
- Linux platform. Linux packages (RPMs) can be installed or updated through the Linux rpm command. Package contents, once installed, however, cannot be modified. Rather, RPM packages are updated using the rpm -U or rpm -F command option, which replaces the current package with a newer package. As a result, you cannot roll back a Linux RPM upgrade unless you have first backed up the original RPM packages.
Java ES RPM package upgrades are encapsulated as patches and assigned a patch ID and revision number similar to Solaris patches. These Linux patches can include one or more RPM packages, each identified by a unique RPM name and a revision number that is incremented as the RPM package is modified over time.
As a convenience, for some Java ES components, you can install Linux patches using the Java ES installpatch script rather than the native rpm commands. The script examines your computer to determine the location of the currently installed component RPM packages and updates the required packages in the correct location and correct order so as to properly upgrade the component.
Accessing Java ES Patches
Patches required to upgrade Java ES components are available through a number of channels:
When a new patch is released, the various patch access channels are synchronized: the accumulated patch cluster and Sun Connection are updated. The patch access channels are described briefly in the sections that follow.
Individual, Discrete Patches
Patches to both Solaris packages and Linux RPM packages are distributed through the SunSolve web site at: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
In situations where you might want a single patch for a particular component within a particular Java ES release family, you can perform a search of patches on SunSolve. You search SunSolve by looking for keywords indicating the release family, for example, the Java ES 5 release family (java_es-5), and the name of the component (shown in Table 1-1 and Table 1-2).
Accumulated Patch Clusters
Accumulated patch clusters (see Java ES Release Families) contain the latest patches for all Java ES components. They are available on the SunSolve web site at: http://sunsolve.sun.com/pub-cgi/show.pl?target=patches/patch-access
If you are looking for the latest available patches for a specific Java ES release family, you can find them in the current accumulated patch cluster for that family. To acquire a Java ES accumulated patch cluster:
Sun Connection (Solaris Platform Only)
Sun Connection is a software update management service by which you are automatically notified of new Java ES point releases. The new patches are automatically downloaded to your computer, where you can apply them at a time of your own choosing. For information, see:
http://www.sun.com/service/sunconnection/index.jsp
Shared Component Upgrades
Java ES shared component upgrades are a necessary part of upgrading the product components that depend on them.
The upgrading of shared components does not require reconfiguration of the components, nor pre- or post-upgrade procedures. In addition, shared component upgrades cannot be rolled back to their previous versions.
The large number (around 30) of Java ES shared components and the complex interactions between shared components and product components requires that all shared components within a single operating system instance be synchronized to the same Java ES release family. An operating system instance means a single computer running the Solaris 9, Solaris 10, or Linux operating system, or any of the virtual operating system environments (zones) on a computer running the Solaris 10 operating system.
Because of the synchronization requirement, you should not perform feature upgrades of Java ES shared components one by one, but rather you need to upgrade all Release 2, Release 3, or Release 4 shared components to their Release 5 or Release 5U1 versions at the same time. When performing a maintenance upgrade, you can selectively upgrade Release 5 shared components to Release 5U1.
The synchronization of shared components to Release 5U1 is achieved using the Java ES installer. The installer synchronizes shared components when performing a feature upgrade of product components (see Using the Upgrade Capability of the Java ES Installer) or when performing a fresh install of product components. The installer also includes a synchronization function that upgrades any existing shared components and installs any missing shared components. For a fuller description of this function, see Synchronize All Shared Components.
Java ES Component DependenciesOne of the most important considerations in an upgrade plan is the dependencies between the various Java ES components in your deployed system. The sequence in which you perform the component upgrades is affected by the nature of the dependencies between them.
This section provides information about Java ES component dependencies that impact your upgrade plan.
Dependencies on Shared Components
Table 1-10 shows the dependencies of Java ES 5 Update 1 (Release 5U1) product components on Java ES shared components. The abbreviations for product components in the column headings of Table 1-10 are taken from Table 1-1. The abbreviations for shared components are listed in Table 1-2.
Within the matrix of Table 1-10 hard upgrade dependencies for Release 3 and Release 4 to Release 5U1 upgrades are marked "H," and soft upgrade dependencies are marked "S." For Release 2 to Release 5U1 upgrades, all shared component dependencies are, by definition, hard upgrade dependencies; all shared components must be upgraded from Release 2 to Release 5U1. For Release 5 to Release 5U1 upgrades, hard upgrade dependencies are indicated with a footnote.
Table 1-10 Shared Component Dependencies of Java ES 5 Update 1 (Release 5U1) Product Components
Shared Component
AM
AS
DPS
DS
DS Console
HADB
JavaDB
MQ
MC
PS
PSRA
SC
SCG
SR
WPS
WS
ANT
S
S
H
H
H
ACL
S
H
BDB
S
CAC
H
S
H1
H1
H1
S
S
S2
S2
FIS
ICU
S
H1
H1
S
S
S
IM-SDK
S
Java SE
S
S
H1
H1
H1
S
H
S
S
S
S
S
S
H
S
S
JAF
S
S
S
S
H
JATO
S
S
S
S
S
S
JavaHelp™
S
S
S
S
S
JavaMail ™
S
S
S
S
H
S
JAXB
S
S
S
JAXP
S
S
S
S
H
S
JAXR
S
S
H
S
JAX-RPC
S
S
H
S
JAXWS
S
JCAPI
JDMK
H
S
H1
H1
H1
S
S
S
S
JSS
S
S
S
S
S
JSTL
KTSE
S
S
S
LDAP C SDK
H
H
S
S
LDAP J SDK
S
MA Core
S
H
H
MFWK
H
H1
H1
NSPR
S
S
H1
H1
H
S
S
S
S
S
S1
H
NSS
S
S
H1
H
S
S
S
S
S
S1
H
SAAJ
S
S
S
S
H
SASL
H
S
S
SEDC
S
S
SJWC
S
S
H1
H1
S
S
WSCL
S
S
H
S
XWSS
H
1Represents a hard upgrade dependency in upgrading from Release 5.
2This dependency is specifically on Common Agent Container (CAC) version 1.1.
The dependencies shown in Table 1-10 for any product component represent both direct and indirect shared component dependencies: a product component might depend on a specific shared component (direct dependency) that, in turn, depends on one or more other shared components (indirect dependency). Figure 1-2 illustrates interdependencies among shared components.
Table 1-10 shows which shared components must be upgraded when you perform an upgrade of one or more product components on a given computer.
However, because shared components must be synchronized to the same release family (see Shared Component Upgrades), you cannot perform a feature upgrade of Java ES shared components one by one, but must upgrade all shared components on a computer or in an operating system instance to their Release 5 or Release 5U1 versions at the same time.
If no hard upgrade dependencies are involved, you need not upgrade shared components. However, it is a good practice to upgrade your underlying Java ES shared component base to the most current version. In fact, when product components are installed or upgraded by the Java ES installer, all shared components residing on the host computer are automatically synchronized to Release 5U1.
For information on how to manually upgrade shared components, consult Chapter 2, "Upgrading Java ES Shared Components."
Figure 1-2 Shared Component Interdependencies
Dependencies on Product Components
Dependencies on product components fall into two general categories: runtime dependencies and configuration dependencies.
- Runtime dependencies. The functioning of a software system is based on the interactions between its deployed components. The infrastructure dependencies between Java ES product components are discussed in the Java Enterprise System 5 Update 1 Technical Overview. If a Release 5U1 product component has a hard upgrade dependency on another product component, the dependent component can only be successfully upgraded and used as intended if the component upon which it depends is also upgraded.
- Configuration dependencies. In some cases a Java ES component must be installed, configured, and running for another component to be configured. For example, a Directory Server user/group directory must be running for an Access Manager service to be registered. Component upgrade procedures often involve reconfiguration of upgraded components or migration of configuration data. Configuration dependencies can impact the sequence of upgrade procedures.
For runtime dependencies, the relationship between product components can be of the following three types:
- Mandatory. The component cannot operate without the supporting component.
- Optional. The component can operate without the supporting component, but a subset of its functionality requires the supporting component.
- Co-Dependency. Both components can operate without the support of the other, but the components used together can provide certain enhanced functionality or performance.
The following table shows the dependencies and dependency relationships between the Java ES product components listed in Table 1-1. The information can be used to determine the hard upgrade dependencies that impact your upgrade plan.
The first column alphabetically lists Release 5U1 product components, the second column shows other Java ES components upon which a Release 5U1 component has a dependency relationship, the third column provides the Java ES release versions that support the Release 5U1 dependency, the fourth column characterizes the dependency relationship, and the last column indicates special characteristics of the dependency, such as whether the supporting component must be local (as opposed to remote) or whether other third-party products can support the dependency.
If a product component you are upgrading to Release 5U1 has a dependency on only Release 5U1 of a supporting component (as opposed to an earlier release), then the supporting component represents a hard upgrade dependency: the supporting component must also be upgraded to Release 5U1.
Table 1-11 Java ES Product Component Dependencies
Release 5U1
Product ComponentDependency1
Java ES Release
Nature of Dependency
Characteristics
Access Manager
Directory Server
2-5 & 5U1
Mandatory: Stores configuration data and enables lookup of user data
J2EE web container:
- Application Server
- Web Server
4-5 & 5U1
4-5 & 5U1
Mandatory: Provides web container runtime services
Local only
Access Manager
SDKAccess Manager
3-5 & 5U1
Mandatory: Provides Access Manager services
Access Manager
Distr. AuthenticationAccess Manager
4-5 & 5U1
Mandatory: Provides Access Manager services
J2EE web container:
- Application Server
- Web Server
4-5 & 5U1
4-5 & 5U1
Mandatory: Provides web container runtime services
Local only
Also supported;
- Weblogic2
- WebSphere3Access Manager
Session FailoverAccess Manager
5 & 5U1
Mandatory: Provides Access Manager services
Message Queue
4-5 & 5U1
Mandatory: Provides reliable asynchronous messaging
Application Server
Message Queue
5 & 5U1
Mandatory: Provides reliable asynchronous messaging
Local only
High Availability Session Store (HADB)
5 & 5U1
Mandatory: Stores session state needed to support failover between instances
Local only
Java DB
5 & 5U1
Mandatory: Provides default developer database and other persistent storage.
Local only
Web Server
3-5 & 5U1
Optional: Provides load balancing between instances
Local only
Directory Proxy Server
Directory Server
1-5 & 5U1
Co-dependency: Results in improved security and performance for directory requests. Supplies data to Directory Proxy Server
Directory Server
Directory Proxy Server
1-5 & 5U1
Co-dependency: Results in improved security and performance for directory requests. Distributes load and caches data from Directory Server
High Availability Session Store (HADB)
None
Java DB
None
Message Queue
Directory Server
2-5 & 5U1
Optional: Stores administered objects and user data
J2EE web container:
- Application Server
- Web Server
2-5 & 5U1
2-5 & 5U1
Optional: Supports HTTP transport between client and Message Queue broker
Java DB
5 & 5U1
Optional: Stores persistent messages.
Local only
Sun Cluster
2-5 & 5U1
Optional: Supports high availability
Monitoring Console
None
Portal Server
Directory Server
4-5 & 5U1
Mandatory: Stores and enables lookup of user profiles
J2EE web container:
- Application Server
- Web Server
4-5 & 5U1
4-5 & 5U1
Mandatory: Provides web container runtime services
Local only
Access Manager or
Access Manager SDK4-5 & 5U1
Mandatory: Provides authentication and authorization services, single sign-on
Local only
(If Access Manager is remote, Access Manager SDK must be used locally)Portal Server Secure Remote Access
5 & 5U1
Optional: Provides secure remote access through the Gateway, Rewriter Proxy, and Netlet Proxy components
Service Registry Client
5 & 5U1
Mandatory: Provides libraries needed for compilation
Java DB
5 & 5U1
Mandatory: Provides support for several portlet applications
Portal Server Secure Remote Access
GatewayPortal Server
5U1
Mandatory: Supports Gateway functionality
Access Manager or
Access Manager SDK4-5 & 5U1
Mandatory: Provides authentication and authorization services, single sign-on
Local only
(If Access Manager is remote, Access Manager SDK must be used locally)Directory Server
4-5 & 5U1
Mandatory: Stores and enables lookup of user data
Rewriter Proxy
Portal Server
5U1
Mandatory: Supports Rewriter Proxy functionality
Netlet Proxy
Portal Server
5U1
Mandatory: Supports Netlet Proxy functionality
Service Registry
Deployment
Application Server
5 & 5U1
Mandatory: Provides container runtime services
Local only
Java DB
5 & 5U1
Mandatory: Provides default database for storing services and related meta data
Local only
Service Registry Client
5U1
Mandatory: Provides required client libraries
Local only
Client
None
Sun Cluster
None
Sun Cluster Agents
Sun Cluster
4-5 & 5U1
Mandatory: Provides access to Sun Cluster services
Local only
Sun Cluster Geographic Edition
Sun Cluster
4-5 & 5U1
Mandatory: Supports Sun Cluster Geographic Edition functionality.
Local only
Web Proxy Server
Directory Server
2-5 & 5U1
Optional: Provides LDAP-based authentication
Web Server
2-5 & 5U1
Co-dependency: Results in improved security and performance for HTTP requests. Supplies data to Web Proxy Server
Also supported;
- Weblogic2
- WebSphere3Web Server
Directory Server
1-5 & 5U1
Optional: Provides LDAP-based authentication
Web Proxy Server
1-5 & 5U1
Co-dependency: Results in improved security and performance for HTTP requests. Distributes load and caches data from Web Server
1For each product component, dependencies are listed in the order that they would normally be upgraded.
2BEA Weblogic Server
3IBM WebSphere Application Server
Upgrade Sequencing GuidelinesThe choice between selective upgrade or upgrade all, the impact of hard upgrade dependencies, and other factors discussed in the previous sections can all affect which Java ES components you plan to upgrade as well as the order in which you need to upgrade them. Nevertheless, a few general sequencing guidelines apply, though not in every case.
The following listing provides the order in which Java ES components can be successfully upgraded on a single computer or in a deployed system. The order is generally more important in feature upgrades (in which dependencies, data formats, and compatibilities might change) than in maintenance upgrades.
When you plan your upgrade, you can omit those components that are not part of your deployment architecture or, if you are performing a selective upgrade, you can omit those components that represent soft upgrade dependencies. If you are performing a maintenance upgrade, you can omit those components for which there is no new maintenance release.
The chapters in this Upgrade Guide are arranged according to the order in which components appear in the following listing.
NoteS
Before upgrading Java ES components, be sure to apply any required update of your operating system (see Required Operating System Patches).
Also check Special Cases to see if any apply to your upgrade scenario.
- Shared Components (See Chapter 2, "Upgrading Java ES Shared Components")
Shared components should be upgraded before the components which depend on them. In most feature upgrades of product components, shared component upgrade is handled by the Java ES installer, however in the case of Web Proxy Server and Portal Server you have to explicitly upgrade shared components. In maintenance upgrades of product components, shared component upgrade can be selectively performed through patching.
- Sun Cluster software (See Chapter 3, "Sun Cluster Software")
If any components run in a Sun Cluster environment, and the Sun Cluster software needs to be upgraded, it should be upgraded before the components that use Sun Cluster services. Sun Cluster agents, if upgraded, should be upgraded as part of the Sun Cluster upgrade.
- Sun Cluster Geographic Edition software (See Chapter 4, "Sun Cluster Geographic Edition")
Sun Cluster Geographic Edition should be upgraded after Sun Cluster software, upon which it depends. It should be upgraded before any components that use Sun Cluster services.
- Directory Server (See Chapter 5, "Directory Server")
Many components store user data or configuration data in Directory Server, so upgrades to Directory Server should generally be performed before upgrading the components that have runtime or configuration dependencies on Directory Server.
- Directory Proxy Server (See Chapter 6, "Directory Proxy Server")
Directory Proxy Server has a soft upgrade dependency on Directory Server and can be upgraded at any time. Some components might access Directory Server through Directory Proxy Server, however, so if Directory Proxy Server is upgraded, it should be upgraded right after Directory Server.
- Web Server (See Chapter 7, "Web Server")
A number of Java ES components require the support of a web container, which, if upgraded, should be upgraded before the components requiring web container services. Normally web container services are provided by Web Server or Application Server, but if your architecture contains both, upgrade Web Server first, before upgrading Application Server.
- Java DB (See Chapter 8, "Java DB")
Java DB must be upgraded before Application Server, which requires Java DB as a default database. However, Java DB is automatically upgraded by the Java ES installer when performing a feature upgrade of Application Server.
- High Availability Session Store (See Chapter 9, "High Availability Session Store")
High Availability Session Store (HADB) must be upgraded before Application Server, which requires High Availability Session Store for high availability. However, HADB is automatically upgraded by the Java ES installer when performing a feature upgrade Application Server.
- Message Queue (See Chapter 10, "Message Queue")
Message Queue must be upgraded before Application Server, which requires Message Queue to be Java Enterprise Edition (Java EE) compliant. However, Message Queue is automatically upgraded by the Java ES installer when performing a feature upgrade Application Server.
- Application Server (See Chapter 11, "Application Server")
Application Server depends on Message Queue and High Availability Session Store, and if upgraded, should be upgraded after these components. Application Server can also depend on Web Server for its load balancing plug in, so if you are using that capability, Application Server should be upgraded after Web Server.
- Service Registry (See Chapter 12, "Service Registry")
Service Registry can be upgraded anytime after Application Server is upgraded because Service Registry depends upon Application Server for runtime container services.
- Web Proxy Server (See Chapter 13, "Web Proxy Server")
Web Proxy Server can be upgraded anytime, though generally it would be upgraded after the Web Server or Application Server component for which it provides a proxy service.
- Access Manager (See Chapter 14, "Access Manager"
Access Manager plays a central role in authentication and authorization, including single sign-on, and, if upgraded, should be upgraded before the components that depend on it for those services.
- Portal Server (See Chapter 15, "Portal Server")
Portal Server depends on many of the preceding components (Directory Server, a web container, and Access Manager), and if upgraded, should be upgraded after these components.
- Portal Server Secure Remote Access (See Chapter 16, "Portal Server Secure Remote Access")
Portal Server Secure Remote Access, must be upgraded when Portal Server is upgraded.
- Monitoring Console (See Chapter 17, "Monitoring Console")
Monitoring Console can be upgraded anytime after the upgrade of shared components.
Special CasesThere are a few special cases to be aware of when planning the upgrade of Java ES components to Release 5U1. These are described below.
Selective Upgrade: Application Server Not Upgraded
If you are performing a selective upgrade of any Java ES component to Java ES 5 Update 1 on a computer that is running Release 3 or Release 4 Application Server (8.1), and you are not upgrading Application Server to Release 5U1, there are situations that must be addressed for Application Server to continue functioning properly:
- JSP compilation errors. Before performing the selective upgrade, you should first apply the Application Server patch shown in the following table.
Table 1-12 Patches1 Needed When Application Server Is Not Upgraded to Release 5U1
Description
Patch ID: Solaris 9 & 10
Patch ID: Linux
Fix for Release 3 and Release 4
Application Server119166-17 (SPARC)
119166-17 (x86)
119168-17
1Patch revision numbers are the minimum required. If newer revisions become available, use the newer ones instead of those shown in the table.
If you fail to apply the patch, Application Server will experience JSP compilation errors. (The patches in Table 1-12 can also be applied retroactively to fix the problem.)
Upgrading Web Server to Release 5U1 Can Require Upgrading Portal Server to Release 5U1
If Portal Server is deployed in a Web Server web container, and if you upgrade Web Server to Release 5U1, you also have to upgrade Portal Server to Release 5U1.
For more information, see the Web Server 7.0 Update 1 Release Notes, http://docs.sun.com/doc/820-1069/6ncp1ddaa?a=view.
Java ES 5 Update 1 Upgrade and Solaris 10 ZonesThis section addresses issues involved in upgrading Java ES software in Solaris 10 zones and provides recommended in such an environment. The section supplements information regarding Java ES 5 Update 1 and Solaris 10 zones in the Java Enterprise System 5 Installation Planning Guide, http://docs.sun.com/doc/819-5079.
It includes the following topics:
Zone Support in the Java ES Installer
The Java ES 5 installer provides qualified zones support for upgrade (as well as installation) of Java ES product components and for synchronization of shared components. Policies have been implemented in the installer to help prevent problematic upgrade scenarios.
Upgrade of Product Components
As described in Using the Upgrade Capability of the Java ES Installer, the Java ES installer can be used to upgrade a limited number of product components and their corresponding shared components. The upgrade capability applies to global zones and all non-global zones.
However, there are three zones-related exceptions to this behavior:
- In sparse root zones, some shared components cannot be installed or upgraded because they reside in read-only directories. In such cases, the upgrade of product components is halted until such time as such shared components have been installed or upgraded in the global zone. The installer provides the following message: "The following shared components, required by the components you have selected, cannot be installed or upgraded in a sparse root zone. Please install or upgrade these shared components in the global zone before proceeding. Use the All Shared Components option."
- Both Application Server and Message Queue are bundled with the Solaris operating system. Neither of these versions can be directly upgraded in a sparse-root zone. For the details regarding these two bundled components, see Product Component Special Cases.
- In a global zone, if non-global zones are present, instead of upgrading all shared components currently installed and installing any missing shared components required by a selected component, the installer synchronizes all Java ES shared components to Release 5U1, whether or not they are needed by any specific product component. This allows all Release 5U1 shared components to be propagated to non-global zones, thus assuring that there is no intermixing of shared component versions in non-global zones.
Note
There are a number of special cases or exceptions that might interfere with the installation or upgrade of product components in non-global zones. These are described in Special Cases or Exceptions.
Synchronize All Shared Components
A shared component synchronization option is provided in Release 5U1 to meet situations in which all shared components must be synchronized to their Release 5U1 versions. When the All Shared Components option is selected, the installer will upgrade all shared components currently installed and install any missing shared components, whether or not they are needed by any specific product component. This option applies to global zones and whole root zones (but not to sparse root zones).
The All Shared Components option, described in more detail in Synchronize All Shared Components, is needed in the following two zone-based upgrade scenarios:
- Manually upgrading product components. The All Shared Components option is needed to perform the shared component installation and upgrade needed when upgrading product components that cannot be upgraded using the Java ES installer.
- Upgrades in a Sparse Root Zone. Some shared components cannot be installed or upgraded in default sparse root zones. Hence, when using the Java ES installer to upgrade product components in sparse root zones, you might first be required to synchronize shared components in the global zone, depending on the shared components involved. You use the All Shared Components option in the global zone to perform the shared component installation and upgrade required in this case.
For a summary of the Java ES installer's zone behavior regarding shared components, see the information regarding Java ES 5 Update 1 and Solaris 10 zones in the Java Enterprise System 5 Installation Planning Guide, http://docs.sun.com/doc/819-5079.
Recommended Upgrade Practices
In formulating an upgrade plan, you should survey any existing multizone deployments of Java ES software, keeping in mind the zones installation and administration strategies outlined in the Java Enterprise System 5 Installation Planning Guide, http://docs.sun.com/doc/819-5079. In some cases you might be required to uninstall components in one or more zones and re-install them in other zones to implement the following recommended practices:
- Avoid mixing strategies. In particular:
- Keep your Java ES zones deployment and administration strategy as simple as possible. Do not mix whole root and sparse root deployments of Java ES components on the same computer. (Procedures and practices needed to support sparse root zone deployments can interfere with whole root zone deployments.)
- Do not install the same Java ES product component in both the global zone and non-global zones, even if they are of different versions. (Procedures needed to upgrade a global zone installation can break the non-global zone installations.)
- When Release 4 (or earlier) Java ES components have been installed in a whole root zone, do not upgrade Java ES components to Release 5U1 in the global zone. Upgrade in the global zone could result in a mixing of Release 4 and Release 5U1 files in the whole root zone.
- Upgrade practices:
- If you want to upgrade all installed Release 4 product components to Release 5U1, synchronize all Java ES shared components in the global zone, then perform the upgrade of the desired product components in the zones where they have been installed. (Release 5U1 shared components are backwardly compatible.)
- If you have Release 4 or Release 5U1 product components installed in a non-zones environment, and you wish to add non-global zones to the environment and install product components in the new non-global zones, you might need to uninstall components in the global zone and reinstall them in non-global zones.
Special Cases or Exceptions
There are a number of special cases, some of which arise from the fact that some Java ES shared components and some Java ES product components are bundled with Solaris 10. By virtue of this bundling, these Java ES components automatically exist in the global zone, and therefore in any non-global zone that is created from the global zone.
Product Component Special Cases
- Message Queue. Message Queue is bundled with Solaris 10, and, as a result, is automatically propagated when non-global zones are created (unless you have first removed Message Queue from the global zone). Message Queue cannot be installed or upgraded in a sparse root zone. When installed or upgraded in a global zone by the Java ES installer, Message Queue, unlike other product components, is, by default, propagated to non-global zones,.
- Application Server. Application Server is bundled with Solaris 10, and, as a result, is automatically propagated when non-global zones are created (unless you have first removed Application Server from the global zone). When propagated in this way, the bundled Application Server, which is installed in /usr, cannot be upgraded by the Java ES installer in a sparse root zone (by default /usr is read-only). To address this problem, the bundled Application Server packages must be manually removed from the global zone before installing the Release 5U1 Application Server in a sparse root zone. See the section on upgrading Release 2 Application Server in the Java Enterprise System 5 Update 1 Upgrade Guide for UNIX, http://docs.sun.com/doc/819-6553.
- Sun Cluster. Sun Cluster software is not supported in non-global zones.
Shared Component Special Cases
- Sun Java Web Console (SJWC). SJWC packages that are bundled with Solaris 10 (Update 1 and Update 2) cannot be removed by the Java ES installer. These older SJWC packages have had the SUNW_PKG_ALLZONES attribute set to True, which means the package must be identical in all zones and can only be managed by the global administrator. As a result, these packages must be manually removed in the global zone and replaced by the correct packages.
If the Java ES installer is attempting to install a selected product component in a non-global zone and detects that SJWC needs to be upgraded, the installer will block. This will happen when installing on Solaris 10, Update 1 and 2.
As a workaround, a special script has been developed that will remove the old packages of SJWC from the global zone and replace them with Release 5U1 SJWC, which has the correct zones propagation attribute value. See the Java Enterprise System 5 Update 1 Installation Guide for UNIX for details.
