Recommended Practices

With Table A–2 in mind, here are a number of recommended practices:

• Plan your Java ES zones deployment strategy in advance depending on the objective in Why Use Zones for Java ES?that you are trying to achieve. Different objectives require different installation and administration strategies, as shown by the different scenarios of Table A–2.

• Avoid mixing scenarios. 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 as in Scenario 3 can interfere with whole root zone deployments as in Scenario 4.)

  • 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 as in Scenario 1 can break the non-global zone installations as in Scenario 4.)

  • When Release 4 (or earlier) Java ES components have been installed in a whole root zone, do not install Java ES Release 5 components (neither product components nor shared components) in the global zone, and do not upgrade Java ES components to Release 5 in the global zone. In other words, Scenario 2 is not supported when there are pre-existing Java ES installations in a whole root zone. (Installation or upgrade in the global zone could result in a mixing of Release 4 and Release 5 files in the whole root zone.)

• Recommended installation practices:

  • If you want to run different Java ES product components in different zones, install the product components in non-global zones (Scenario 2, 3, 4, 5).

  • If you want to run different Java ES product components in different zones but centrally manage shared component life cycles, synchronize shared components in the global zone, then install the product components in non-global zones (Scenario 2, 3). (This is a recommended practice whenever installing product components in sparse root zones.)

  • If you want to achieve version separation of Java ES product components or, for other reasons to isolate deployments of Java ES product components (Scenario 4), then install and configure all Java ES components in whole root zones. Do not install any Java ES components in the global zone.

• Recommended upgrade practices:

  • If you want to upgrade all installed Release 4 product components to Release 5, 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 5 shared components are backwardly compatible.)

  • If you have Release 4 or Release 5 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, be sure to do so in accordance with the recommended practices above. This might mean uninstalling components in the global zone and reinstalling them in non-global zones.