Installing Sun Java System Application Server 9.1 in Solaris Zones

Print-friendly Version

This article will help you understand how to install Sun Java System Application Server 9.1 in Solaris 10 zones. It explains the possible installation and upgrade scenarios, their limitations, and how to overcome them.

• Solaris Zones and Application Server
• Getting Into Application Server and Solaris Zones
• Installing Application Server in the Global Zone
• Installing Application Server in a Sparse Zone
• Installing Application Server in a Whole-Root Zone
• Summary
• References

Sun Java System Application Server 9.1 is the Sun-supported distribution of the open-source GlassFish version 2 application server. This article will henceforth use the term Application Server to embrace both of them, except when it is important to make a distinction.

Throughout this article, the terms Solaris and Solaris OS refer to the Solaris 10 Operating Environment, unless otherwise indicated.

Solaris Zones are useful in deployments where centralized software management and high reliability are important. Some special considerations arise when Application Server is installed in Solaris zones.

A Solaris zone is a partitioned virtual OS environment within the Solaris OS. Each zone acts as completely isolated virtual server within a single machine. A zone is a primitive that, when used with the operating system's resource management facility, is known as a Solaris container.

An application sees a zone as an isolated and secure operating system environment. Hence, you can isolate applications from one another by installing them in different zones, yet maintain centralized management of certain operating system resources.

From the point of view of an operating system supporting multiple zones, operating system resources include resources such as process management, memory, network configuration, file systems, package registries, user accounts, shared libraries, and, in some cases, installed applications.

One zone is always defined in the Solaris OS: the global zone. The global zone is the traditional OS environment where Solaris OS is installed. The global zone may contain other zones. Zones hosted by a global zone are known as non-global zones, or simply zones.

Zones can be created with a minimal amount of disk space. These zones are called sparse zones. Alternatively, you can create a whole-root zone, which duplicates the entire operating system.

The following figure illustrates the relationship between zones, the global zone, the operating system kernel, and the underlying hardware resources.

Figure 1. Solaris Zones Isolate Applications Click here for a larger image

For a more extended overview, see the OpenSolaris Zones and Containers FAQ. For detailed information, see the System Administration Guide: Solaris Containers–Resource Management and Solaris Zones.

Application Server (both Sun Java System Application Server 9.1 and GlassFish version 2) is available in source download and as binaries. Binaries are also distributed in native package-based format (RPM packages on the Linux OS and SVR4 packages on the Solaris OS). This article covers only installation of native Solaris package-based binaries, installed through the downloadable standalone package-based installer. You can install file-based installers, typically in zip format, anywhere without limitation on zones support as long as you install in writable directories.

The following installation options illustrate possible sources of confusion when Application Server is installed or upgraded in Solaris zones.

• Application Server bundled in Solaris OS 10 – Version 8.x of Sun Java System Application Server is bundled with the Solaris 10 OS and is installed under /usr/appserver.
  
  
• Sun Java System Message Queue bundled in Solaris OS 10 – Version 3.7 Update Release 1 of Sun Java System Message Queue (hereafter referred to as Message Queue) is bundled with the Solaris 10 OS and is installed under /usr.
  
  
• Pre-installed version of Java Enterprise System (Java ES) – An earlier version of Java ES packages may be installed in any zone. In such cases, the Java ES installer automatically handles the upgrade of the versions of Application Server and Message Queue that were installed by the previous Java ES installer. Note, however, that Message Queue can be upgraded only in the global zone and in whole root zones, not in sparse zones.
  
  
• Differing SVR4 package propagation levels – Propagation in zones of Application Server packages and related components can vary depending on how they were installed. For example,
  
  
  • In the case of Application Server bundled in Solaris, the packages are set to propagate to all zones. As a result, removing a package from the global zone removes its reference in sparse zones.
    
    
  • When Solaris-bundled Application Server packages are upgraded by the Java ES installer, their propagation levels are reset to “global zone” only.
    
    
  • The Application Server installer also carries a set of shared components, among them Sun Java System Message Queue 4.1, High-Availability Database 4.4.3-6 (HADB), and JDK 5 Update 12. Application Server installer automatically upgrades these components upon detection of an earlier version in global and whole-root zones. HADB can be upgraded in a sparse zone.
    
    
  • The Application Server and HADB packages part of the Sun Java System Application Server 9.1, when installed in the global zone, are not propagated to other zones. As a result, it is possible to have multiple versions of Application Server installed in non-global zones without conflicting with the version installed in the global zone.
    
    
  • In contrast, shared components and Message Queue packages are always propagated to all zones when the Application Server is installed in the global zone.
    

This following sections examine the types of existing Application Server zone installations and their implications for a new installation.

Before Application Server is installed in the global zone, one of the following conditions will be true for the installation environment:

1. A Solaris-bundled version of Application Server has been installed in the global zone.
   
   
2. A version of Java ES software has been installed.
   
   
3. No bundled Application Server has been installed, and no earlier version of Java ES has been installed. The environment is “clean,” with no Application Server installed.
   

Obviously, if your environment is clean (case 3 above), then you can install with the Application Server installer directly with no negative or unforeseen consequences. We now examine the first two cases and their implications.

To determine if there is a bundled Application Server in the global zone, you will need to take the following steps.

1. Look for Application Server SVR4 packages in the system. You can find the official list of Application Server packages installed as part of Solaris 10 in the online Sun OS Package List.
   
   From this list, look for the following Application Server packages: SUNWasac, SUNWascmn, SUNWasdb, SUNWasdem, SUNWasdemdb, SUNWasjdoc, SUNWasman, SUNWasr, SUNWasu, and SUNWasut. If you have Solaris 10 Update 3 or above, then you also have the SUNWasjavadb package (a private version of Java DB used only for Application Server).
   
   
2. Find and validate the bundled Application Server installation directory contents. The Application Server version bundled in Solaris 10 is always installed under /usr/appserver. To determine the version of Application Server, run the command /usr/appserver/bin/asadmin version -v. This command execution path ensures that you are not looking at a Java ES installed under /usr/appserver. Make a note of the version number. It is useful in considering how to perform subsequent installations.
   
   
3. Check to see if a default domain created from an Application Server bundled in Solaris exists and is being used. If the domain is active and is being used but you do not know where it is located, use the following procedure to find it by examining the Application Server product-wide configuration file asenv.conf. Locate the path to the file as follows:
   
   
   1. View the contents of the file /usr/appserver/bin/asadmin in an editor and search for the string asenv.conf. The line containing this string in the asadmin file shows the absolute path to the asenv.conf file.
      
      
   2. Having located the asenv.conf file, open it to find the location of the default domains for the installation. The AS_DEF_DOMAINS_PATH token contains the value of the domains root directory under which the default domain and newly created domains are located. Note that you can change this path with the override option --domaindir.
      

If you discover that a bundled version of Application Server has been installed on your system, you must now consider the following implications for further installations and upgrades.

• If your system has a bundled version of Application Server in the global zone, then you must recognize that the Application Server and Message Queue packages that are installed in global zone are by default set to propagate to other zones. If you want to use sparse zones, each perhaps with a separate Application Server, then you must uninstall the global zone installation of Application Server. To uninstall, remove all of the SVR4 packages listed above from the Sun OS Package List.
  
  
• If you do not plan to use sparse zones with separate Application Server installations, you do not need to remove the SVR4 packages.
  

After you have uninstalled Application Server from the global zone, you can install Application Server either in a new directory or by upgrading an existing installation directory, overwriting necessary files. If you choose to use an existing directory and overwrite the prior version, select /usr as the installation directory. appserver will be appended automatically to the installation path.

One advantage to having Application Server installed in the global zone under /usr is that, because this directory is visible to other sparse zones (mounted as a read-only entry), the Application Server binaries can be used to create domains in sparse zones. Note that wherever Application Server tries to write files (domains, database log, properties files, and so on) it must be directed to a writable directory. You can specify directories when you invoke the asadmin command. For example, the following command creates an administrative domain in writable_dir/domains, a directory for which Application Server has write permission:

asadmin create-domain --domaindir writable_dir/domains

Similarly, the following command starts the Java DB server and specifies writable_dir as the directory where the derby.log file and other database files are stored:

asadmin start-database --dbhome writable_dir

For help with asadmin utility commands, type asadmin, then type help at the asadmin> prompt. See also the Sun Java System Application Server 9.1 Administration Guide for a list of all available administration commands and their options.

The locations of default domain directories created during the Sun Java System Application Server 9.1 and Java ES installations are different. For Java ES, the default location is /var/opt/SUNWappserver/domains. Unlike Java ES installer, the Application Server installer does not let you choose a domain root directory, and the domain is always created under the Installation directory chosen during installation time. As a result, you do not need to worry about overwriting the domains directory unless the domain root and install root were explicitly set to the same directory during installation of Java ES.

Sun Java System Application Server 9.1 installer only supports upgrading from Java ES 5 Update 1. If you have an earlier version of Java ES, first upgrade to Java ES 5 Update 1, then run the Sun Java System Application Server 9.1 installer.

Java ES 5 Update 1 bundles and installs Sun Java System Application Server 8.2 Update 1 Enterprise Edition. This version and Sun Java System Application Server 9.1 carry the same SVR4 package names. Therefore, it is not possible to install the two different versions on the same machine. Because the default domain directory is different in each installer, phase your upgrade as follows:

1. Upgrade binaries by removing existing Application Server packages installed as part of Java ES 5 Update 1. Then, install Sun Java System Application Server 9.1 packages in the directory of your choice. This process is automated through Sun Java System Application Server 9.1 installer.
   
   
2. After the binary upgrade, run the Upgrade Wizard for Sun Java System Application Server 9.1. You can start this tool with the bin/asupgrade command from the location of the newly installed Application Server. In the Upgrade Wizard, specify the Java ES 5 Update 1 domain directory as the Source Domain Directory and the Sun Java System Application Server 9.1 domain directory as the Target Domains Root Directory.
   

For more information, refer to the Sun Java System Application Server 9.1 Upgrade and Migration Guide

From a zones perspective, it is important to note that the propagation levels of packages installed through Java ES 5 Update 1 are not changed when you upgrade Application Server to Sun Java System Application Server 9.1.

Sparse zones are used for deployments in which a single installation in the global zone must be shared among all users in an organization. Sparse zones are inexpensive to create. One advantage of using sparse zones is that the installation when patched from a global zone is visible in all of the sparse zones.

Installing into a sparse zone is more difficult than installing into the global zone because of the complications described below.

Application Server Is Installed in the Global Zone From a Solaris Bundle

To determine if there is a bundled Application Server in the global zone, take the following steps.

1. Look for Application Server SVR4 packages in the system. You can find the official list of Application Server packages installed as part of Solaris 10 in the online Sun OS Package List.
   
   From this list, look for the following Application Server packages: SUNWasac, SUNWascmn, SUNWasdb, SUNWasdem, SUNWasdemdb, SUNWasjdoc, SUNWasman, SUNWasr, SUNWasu, and SUNWasut. If you have Solaris 10 Update 3 or above, then you also have the SUNWasjavadb package (a private version of Java DB used only for Application Server).
   
   
2. Find and validate the bundled Application Server installation directory contents. The Application Server version bundled in Solaris 10 is always installed under /usr/appserver. To determine the version of application server, run the command /usr/appserver/bin/asadmin version -v. This command execution path ensures that you are looking at a version of Application Server that was bundled with Solaris, not a version that was bundled with Java ES and installed under /usr/appserver.
   
   
3. Check to see if a default domain created from an Application Server bundled in Solaris exists and is being used. If the domain is active and is being used but you do not know where it is located, use the following procedure to find it:
   
   
   1. View the contents of the file /usr/appserver/bin/asadmin in an editor.
      
      
   2. Search the asadmin file for the string asenv.conf. The line containing this string shows the absolute path to the asenv.conf file.
      
      
   3. Open the asenv.conf file to find the location of the default domains for the installation. The AS_DEF_DOMAINS_PATH token contains the value of the domains root directory under which the default domain and newly created domains are located. Note that you can change this path c with the override option --domaindir.
      

After you have confirmed that a bundled version of Application Server still exists in the global zone, uninstall it by removing all packages listed in step 1. Then, use the pkgrm command to examine and delete the contents of the /usr/appserver directory in the global zone.

Note that the removal of Application Server from the global zone is propagated to the sparse zone because the bundled version of Application Server has packages that are set by default to propagate to all zones.

Message Queue Is Installed in the Global Zone From a Solaris Bundle

Like Solaris bundled Application Server, Message Queue packages are also installed under the /usr directory of the global zone and hence cannot be overwritten from a sparse zone. Message Queue packages are not relocatable and are always installed under /usr, which is a read-only mount point in a sparse zone.

Therefore, before installing Application Server binaries in a sparse zone, use the Application Server installer to install Message Queue in the global zone.

You can install or upgrade Message Queue in the global zone by one of the following methods. Either one makes sure that packages are upgraded if an earlier version is found.

1. You cannot explicitly select the Message Queue components in an Application Server installation. They are hidden and are automatically selected or deselected for installation when you install other components. Message Queue components are always selected when you select any installable component of Application Server. For example, run the Sun Java System Application Server 9.1 installer and select Sample Applications to install Message Queue 4.1 as part of an Application Server installation.
   
   
2. Alternatively, use your browser to navigate to the Open Message Queue download page, click the appropriate Solaris link under "Latest Open MQ 4.1 GUI Install Downloads" and install the Message Queue 4.1 SVR4 packages.
   

Application Server Is Installed in the Global Zone by Java ES

If the Application Server has been installed in the global zone as a result of a Java ES installation, then the shared components and Message Queue installed in the global zone will be propagated to sparse zones, but the Application Server will not.

To install Application Server in a sparse zone:

1. Before installing in a sparse zone, perform the following preliminary steps:
   
   
   1. Run the Sun Java System Application Server 9.1 installer in the global zone.
      
      
   2. In the installer, select HADB or Sample Applications.
      
      
   3. Choose to install JDK and to upgrade all the components.
      
      
2. Install the Application Server in the sparse zone.

Application Server Is Installed in a Sparse Zone by Java ES

To upgrade a Java ES-installed Application Server in a sparse zone:

1. Run the Sun Java System Application Server 9.1 installer in the global zone.
   
   
   1. In the installer, select HADB or Sample Applications.
      
      
   2. Choose to install JDK and to upgrade all the components.
      
      
2. Run the Sun Java System Application Server 9.1 installer in the sparse zone to upgrade the Java ES installation in the sparse zone.
   
   
3. After the binary upgrade, run the Upgrade Wizard for Sun Java System Application Server 9.1. You can start this tool with the bin/asupgrade command from the location of the newly installed Application Server. For more information, refer to the Sun Java System Application Server 9.1 Upgrade and Migration Guide.
   

Application Server Installed in Global Zone by Sun Java System Application Server 9.1 Installer

If the Application Server has been installed in the global zone by the Application Server installer, then a different version of Application Server can be installed in a sparse zone because Application Server packages do not propagate to a sparse zone.

Installing Application Server in a Whole-Root Zone

A whole-root zone has packages copied from the global zone; these packages can be propagated. Whole-root zones increase configuration flexibility because their packages can be patched locally even though they are copies from the global zone.

Installing Application Server in a whole-root zone is much simpler than installing in other zones. All components of the Application Server (including shared components, Message Queue, and HADB) can be installed without regard to packages in other zones, including global and sparse zones.

Summary

Solaris zones are very effective and useful for a variety of purposes, but they can introduce complications into Application Server installations. You must consider many factors that affect propagation and precedence between global and non-global zones when you install Sun Java System Application Server 9.1 or GlassFish version 2 into a zone.

References

• Sun Java System Application Server 9.1 – product page
• OpenSolaris Zones and Containers FAQ
• System Administration Guide: Solaris Containers – Resource Management and Solaris Zones.
• Sun OS Installation Package List
• Sun Java System Application Server 9.1 High Availability Administration Guide
  
• Download Page for GlassFish Community
  
• The Aquarium – GlassFish Community Wiki
  
• Java EE Learning Path – Training Course Catalog
• Sun Developer Expert Assistance
• Sun Java System Application Server page – with links to the GlassFish Community site
• Java Training and Certification – professional development to enhance your skills
• Developer Support – online incident-based programming advice, telephone product support, developer training courses, service plans
• Sun Java System Application Server Support

Rate and Review Tell us what you think of the content of this page. Excellent   Good   Fair   Poor   Comments: Your email address (no reply is possible without an address): Sun Privacy Policy Note: We are not able to respond to all submitted comments.