Java ES Shared Components and Zones

The discussion in Why Use Zones for Java ES? focused on the use of zones by Java ES product components: those that can be explicitly selected in the Java ES installer and installed and configured in various zones to achieve a desired deployment architecture and functional capability. However, the shared components upon which product components depend set a number of limitations on how Java ES is deployed in a multi-zone environment. There are two issues regarding Java ES shared components and zones:

Synchronization of Shared Components

The difficulty of testing and supporting the large number (around 30) and complex interactions between Java ES shared components and Java ES product components mandates that all shared components within a single operating system instance be synchronized to the same Java ES version. In other words, all Java ES shared components installed in a non-zone environment, or in any single zone within a Solaris 10 environment, must be of the same version. This requirement sets certain restrictions on how Java ES can be used in a multi-zone environment.

This synchronization requirement has the following implications:

• Different versions of Java ES shared components can only reside in different zones. For example, you can install Java ES Release 4 shared components in one zone and Java ES Release 5 shared components in another zone, but you cannot combine them in the same zone.

• If any shared component in a zone is upgraded or any new shared component of higher version is introduced, then all shared components in that zone must also be upgraded at the same time. (Shared components are required to be backwardly compatible, so there is no problem for Release 4 product components to work with Release 5 shared components.) For example, suppose a Release 5 product component is installed in a zone in which one or more Release 4 product components reside. Because the Release 5 product component requires some number of Release 5 shared components, the synchronization requirement means that all Release 4 shared components residing in that zone must be upgraded to Release 5 at the same time the Release 5 product component is installed. This is the case even if the Release 5 product component being installed requires different shared components from those that are already installed in the zone.

• When shared components are installed in and propagate from the global zone (see Java ES Propagation Policies), then special care must be taken to maintain synchronization of shared components in all zones. Otherwise it would be possible for shared components of an earlier version in a non-global zone to be mixed with Release 5 shared components that have been propagated from the global zone. (Special care normally means that shared component life-cycle management takes place only in the global zone. For more information see Table A–2, and Shared Component Special Cases.)

The shared component synchronization requirement imposes restrictions on what the Java ES installer is constrained to do in a multi-zone environment (for more information, see Zone Support in the Java ES Installer) and also impacts procedures for installing and upgrading Java ES product components in a multi-zone environment.

Shared Components and Sparse Root Zones

Another issue impacting the use of Java ES in a multi-zone environment is that a large number of shared components cannot be installed in sparse root zones because of the read-only file systems in sparse root zones. Hence, those shared components whose base directory is /usr (a directory that by default is shared by the global zone) must be installed in the global zone to be available in a sparse root zone.

The inability to install a number of Java ES shared components in sparse root zones means that to successfully install product components which have dependencies on such shared components into sparse root zones, the shared components must first be installed in the global zone and propagated to non-global zones.