Installing Maintenance Updates and Service Packs
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
This section includes the following topics:
After you download and apply patches that contain classes to be loaded into a classpath, such as the WebLogic system classpath or the classpath of an application deployed on WebLogic Server, you need to make sure that those classes are properly inserted into the appropriate classpath; otherwise they will not take effect. Likewise, if a patch contains library files to be inserted into the library path, you need to make sure that the paths for those files are properly handled when the server instances or applications by which they are used are started.
This section introduces two of the basic tasks that you must perform to make sure that the patches you apply to your domains become effective:
You can assume that your classpath and library path patches will be picked up properly when the domain servers are started, without your having to modify any start scripts, if:
Under other conditions, however, you need to take additional steps to ensure that patches are inserted into the appropriate classpath or library path when your BEA product servers are started. These additional steps are necessary if either of the following statements characterize the environment in which you have applied patches to your BEA products:
commEnv
script:If you use custom start scripts, or if you need to limit the scope of a patch to a specific domain or server, you must modify your start scripts as follows:
To learn how to modify start scripts so that the class and library path patches you have applied are properly used, see the following sections:
Smart Update does not use a single method to apply all patches to a product installation; the method used depends on the type of patch and its contents. Patches may contain any of the following:
Review the following sections to learn how patches are applied in a BEA Home directory and how Smart Update organizes those patches on your machine. Understanding these processes is necessary in order to determine whether and how your start scripts need to be modified:
If a patch contains class or library files that are loaded by a start script, those classes or files are stored, by Smart Update, in a central, installation-level patch directory on the machine. These classes and library files are then available for loading when the WebLogic Server instances by which they are used are started.
Examples of patches in this category are those that contain the following:
Note: Although a patch may be validated and applied to a target installation at any time, some patches do not become effective immediately. Any patch that contains either (a) classes to be loaded into a classpath, or (b) native library files to be loaded into a library path, does not become effective until you:
(1) Modify the appropriate domain or server start scripts, if necessary, so they point to the patch.
(2) Restart the corresponding domains or servers.
Patches that replace existing resources in a product installation become effective, automatically, throughout the installation, as soon as they are applied; they are not enabled by a start script. Therefore, you do not need to modify start scripts for patches that contain replacements for system resources.
Examples of patches that typically contain replacement artifacts include the following:
Note: Smart Update stores files that have been replaced in the backup
subdirectory of the installation-level patch directory. If you subsequently remove the patch in which a replacement was delivered, the original resource is restored from backup
. (For details about backup
, see Table 5-1.) For optimal security, however, BEA also recommends that you create a backup of any system resource that you plan to replace before applying the patch that replaces it.
When you download a patch or patch set from BEA Customer Support, a patch container is placed in the patch download directory. A patch container holds the following:
Metadata is information used by Smart Update to validate each patch against all other patches applied to the same product installation. (When you apply a patch, metadata is placed in a patch registry in a directory on your machine that is maintained by Smart Update. For details, see Structure of the Installation-Level Patch Directory.)
When you apply a patch to a given patch profile, each file in the patch is handled as follows:
PATH
or LIBPATH
environment variable, Smart Update performs the following tasks:native
that is specific to the currently selected patch profile. If Smart Update does not find such a subdirectory, it creates one. For a description of the native
subdirectory, see Table 5-1. After you install BEA Products software and run Smart Update, the patch directory BEA_HOME
\patch_weblogic910
is created. Figure 5-1 shows the structure of this directory, and Table 5-1 describes its contents.
Figure 5-1 Installation-Level Patch Directory
Contains the patch backup manifest, which includes files and information required to restore an earlier patch level on your machine. This directory is created when you apply an installation-wide patch that contains files to be placed in the product installation directory. |
||
Patch JAR files, containing the class JAR files from patches that have been applied to the BEA product installation on the machine. A patch JAR file may contain one or more of the following:
Note: Patch JAR files containing replacements for system resources are not stored in this directory ( Note: It is good practice to make sure that your machine contains enough disk space for the patch JAR files being added. For information about the size of a patch containing a JAR file, see Viewing Patch Information. |
||
Directory tree for all patch profiles created for a product installation, containing the following directories:
|
||
This information is used internally by Smart Update to perform tasks such as patch validation. |
Patches that contain classes that supersede existing, same-named classes when they are inserted into a classpath are referenced by a patch manifest JAR. When you apply a patch that contains such classes to a patch profile, the patch manifest JAR file of that profile is automatically updated by Smart Update to reference the classes in the patch.
For example, if a patch contains a JAR file called CR99004.jar
, which contains WebLogic system-level classes, and that patch is applied to the default patch profile, Smart Update performs the following tasks:
If a patch contains native library files that are to be loaded into the system library path when the corresponding WebLogic Server instance is started, those library files are stored in the native
subdirectory for the patch profile to which the patch has been applied.
For example, if the patch contains the file libmuxer.so
, which is to be loaded into the system library path when the server is booted, and the patch is applied to the default patch profile, Smart Update does the following:
To make sure that a patch is loaded into a classpath or the system library path when a WebLogic Server instance is started, you may need to add a pointer to the patch to the start script for that server. The following sections explain how Smart Update works and describe the modifications that you may need to make to your start scripts:
When a WebLogic Server instance is booted, several startup scripts are executed. One of the tasks performed by these scripts is to define class and library paths used by the system, including the WebLogic system classpath. By default, all WebLogic Server instances use the class and library path definitions set in one of the following scripts:
WL_HOME
\common\bin\commEnv.cmd
The commEnv
script includes default definitions for the environment variables described in Table 5-2. By default, these patch path variables are in effect for every WebLogic Server instance that is started, and they point at patches that are to be inserted into class and library paths.
Within the commEnv
script, the patch path variables described in Table 5-2 are inserted into statements that set the system classpath, library path, and so on, as appropriate. For example, the following default statement in the commEnv
script sets the WebLogic system classpath. The variable PATCH_CLASSPATH
, at the beginning of the classpath definition, is shown in bold.
set WEBLOGIC_CLASSPATH=
%PATCH_CLASSPATH%;%JAVA_HOME%\lib\tools.jar;
%WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\weblogic.jar;
%WL_HOME%\server\lib\webservices.jar
When the commEnv
script is executed at server boot time, the classes and library files referenced by these patch path variables are loaded, overriding any classes or library files of the same name that are listed later in the classpath or path statement.
Figure 5-2 shows a patch JAR file that contains classes referenced through the PATCH_CLASSPATH
environment variable and loaded into the WebLogic system classpath by the commEnv
script.
Figure 5-2 Patch JAR File Classes Referenced by PATCH_CLASSPATH Variable
If the patch path variables described in Default Script that Defines Class and Library Paths for All Domains and Servers were defined in a script, such as startWebLogic
or setDomainEnv
, that you executed earlier to start instances of WebLogic Server, the existing definitions for those server instances are retained; they are not overridden by the variable definitions in commEnv
.
For example, if the setDomainEnv
script for the MyTestDomain domain contains a definition for the PATCH_CLASSPATH
variable that is used by all WebLogic Server instances in MyTestDomain, the definition of PATCH_CLASSPATH
in the commEnv
script is overridden for those server instances. For this reason, it is important that if you add a patch path variable definition to a start script, that the definition is placed before the statement that invokes another start script.
It is important for each WebLogic Server instance to start properly with any required patches. If your environment is customized in a way that requires you to define one of the patch path variables with which you start your WebLogic Server instances, you need to understand the following:
Once you understand the sequence in which the start scripts in your environment are executed, and the locations from which start scripts are invoked, you can determine which script needs to be modified and make sure that the correct values are assigned to all required patch path variables for all target server instances.
BEA provides a default set of scripts that:
These scripts are executed in a specific order, which is determined by the content of each script.
Table 5-3 identifies:
When you create a domain using the Configuration Wizard, note the following about the placeholders for defining patch path variables in the scripts that are created for that domain:
setDomainEnv
script contains the following lines, which are commented out by default:@REM If you want to override the default Patch Classpath, Library Path
and Path for this domain,
@REM Please uncomment the following lines and add a valid value for
the environment variables
@REM set PATCH_CLASSPATH=[myPatchClasspath] (windows)
@REM set PATCH_LIBPATH=[myPatchLibpath] (windows)
@REM set PATCH_PATH=[myPatchPath] (windows)
@REM PATCH_CLASSPATH=[myPatchClasspath] (unix)
@REM PATCH_LIBPATH=[myPatchLibpath] (unix)
@REM PATCH_PATH=[myPatchPath] (unix)
The Configuration Wizard provides these commented lines as an aid to helping you place definitions for patch path variables. For example, if you want to point the domain to the patch JARs in the custom profile MyProfile, you might uncomment the placeholder for the PATCH_CLASSPATH
variable and define it as follows:
PATCH_CLASSPATH=%BEA_HOME%\patch_weblogic910\profiles\MyProfile\sys_manifest_classpath\weblogic_patch.jar
Refer to Table 5-2 for the definitions of these variables that are included by default in the commEnv
script.
To help with adding definitions of patch path variables, Smart Update provides the Start Script Editor, described in Using the Start Script Editor.
Note: A start script should reference no more than one patch manifest JAR file for WebLogic system-level classes. If a start script references more than one such file, unpredictable behavior may occur at run time.
startWebLogic
and startManagedWebLogic
start scripts produced by the Configuration Wizard do not contain placeholders for defining patch path variables. If you add a definition for one or more of these variables to one of these scripts, be sure that you understand which WebLogic Server instances are affected.
The specific tasks you need to perform to ensure that a start script references the classes or library files patches in a profile depend on whether the scope of those patches is intended for all domains and servers running on the BEA product installation, or only for a specific domain or server in that installation.
For detailed information about modifying a start script, see the appropriate instructions, as described in the following table.
The modifications required for start scripts to reference the class and library path patches in effect for all domains and servers |
Pointing All Domains and Servers at Patches Through Custom Scripts |
The modifications required for starts scripts to reference the class and library path patches in effect for a specific domain or server |
|
Creating a custom patch profile, which you must do before modifying scripts to point a domain or server at patches |
The Smart Script Editor is a tool, provided by Smart Update, for locating start scripts in your environment and assisting with creating definitions for patch path variables in them. To use the Start Script Editor, complete the following steps:
For detailed instructions, see Opening a Start Script.
The Start Script Editor provides code snippets with suggested definitions for the PATCH_CLASSPATH
, WEBLOGIC_EXTENSION_DIRS
, PATCH_LIBPATH
, and PATCH_PATH
variables, all of which are customized for the previously-selected patch profile. You may want to modify these definitions, however, depending on your needs:
—If you are modifying your script to point to the patches in the default patch profile, see Pointing All Domains and Servers at Patches Through Custom Scripts for instructions.
—If you are modifying your script to point to the patches in a custom patch profile, see Patching Individual Domains or Servers, to learn how to create a custom patch profile and add pointers to that profile to the start script for a domain or server.
Note: When adding a definition of a patch path variable to a start script, make sure that the definition appears before any statement that invokes another start script. For example, if you add a patch path variable definition to the setDomainEnv
script, add it before the statement that invokes the commEnv
script. This placement ensures that the definition you add is not overridden by a definition appearing in any of the start scripts that are subsequently invoked.
Smart Update does not enforce or control how you modify start scripts. If, however, you use the start scripts that are created by default by standard tools such as the Configuration Wizard, and maintain them in the default locations determined by those tools, Smart Update can provide a more structured and predictable means to locate the appropriate start scripts that need to be modified for the purposes of pointing to the patches in a patch profile.
The Start Script Editor dialog box is not a wizard; it does not perform the following tasks:
If you have customized your server and domain start mechanisms, you may need to take additional steps beyond working with the Start Script Editor to make all the necessary changes.
When you open a start script, by clicking Open in the Start Script Editor dialog box, Smart Update displays the Open Start Script dialog box. Use this dialog to locate the start script in which you want to add pointers from a domain, Managed Servers, a cluster, or an individual server to the patches in a patch profile.
In the Start Script Editor dialog box, the icons described in Table 5-4 are used to guide you to the directory containing the start script you want to modify.
If you use the directory structure created for a domain by the Configuration Wizard, Smart Update guides you to the directories containing the start scripts you need to modify.
For information about locating a specific start script to modify, see the following topics:
To modify the start script for a domain, select the setDomainEnv
or startWebLogic
script in the domain's bin
subdirectory. Figure 5-3 shows how to select the setDomainEnv
script on a Windows system.
Figure 5-3 Selecting the setDomainEnv Script in the Select Start Script Dialog Box
The setDomainEnv
script contains placeholders for definitions of the PATCH_CLASSPATH
, PATCH_LIBPATH
, and PATCH_PATH
variables. For information about modifying this script, see the following table.
The placeholders for definitions of the |
Placeholders for Defining Patch Path Variables in Default Scripts |
This script to point to the patches in the default patch profile |
Pointing All Domains and Servers at Patches Through Custom Scripts |
This script to point to the patches in a custom patch profile |
To modify the start script for all Managed Servers in a domain, which by default includes all servers in a cluster, select the startManagedWebLogic
script in the domain's bin
subdirectory, as Figure 5-4 on a Windows system.
Figure 5-4 Selecting the startManagedWebLogic Script in the Select Start Script Dialog Box
For information about modifying this script, see the following table.
To modify the start script for a particular server in a domain, select the uniquely-named start script for that server in the domain's bin
subdirectory. Figure 5-5 shows how to select the start script startWebLogicServer1
on a Windows system.
Figure 5-5 Selecting a Server Start Script in the Select Start Script Dialog Box
For information about modifying this script, see the following table.
It is important to make sure that class and library patches are properly loaded into the class and library paths used in your domains. If the scripts used in your WebLogic domains to start servers or set up the environment do not invoke the default commEnv
script, as described in Default Script that Defines Class and Library Paths for All Domains and Servers, you should modify those scripts as follows:
Make sure you add this functionality of the default commEnv
script to your own scripts through any of the following methods:
When the domains and servers in your environment are started, the patch JARs that have been applied to the default patch profile should be inserted into the WebLogic system classpath. To make sure that the patch JARs are inserted into this classpath properly, you must add, to your start script, the code described in this section.
if "%PATCH_CLASSPATH%" == "" set PATCH_CLASSPATH=
BEA_HOME
\patch_weblogic910\profiles\default\sys_manifest_classpath\weblogic_patch.jar
This definition enables individual servers or domains to override this definition, if there is a need for those servers or domains to point to the patches in a custom patch profile. In this definition, BEA_HOME
represents the BEA Home directory path. You can specify an absolute path, or use an environment variable, such as BEA_HOME
, which you have previously defined (recommended).
If your default patch profile contains patch JARs for applications that are deployed on WebLogic Server for a BEA product, you can define the WEBLOGIC_EXTENSION_DIRS
environment variable to point to the patch JARs for that application as follows:
if "%WEBLOGIC_EXTENSION_DIRS%" == "" set WEBLOGIC_EXTENSION_DIRS=%BEA_HOME%\patch_weblogic910\profiles\default\sysext_manifest_classpath
Note: The WEBLOGIC_EXTENSION_DIRS
variable is reserved for use by BEA products that require the classes in a patch JAR file to be loaded into the classpath of an application that is deployed on WebLogic Server. This mechanism for patching deployed applications is not currently being used with WebLogic Server 9.1.
It is important to make sure that the native files that have been applied to the default patch profile are inserted into the system library path, whenever any of the domains or servers in your environment are started. To make sure these files are inserted properly, add the code provided in this section to the script that you have chosen to point to the patches applied to the default patch profile.
To add this code to your script, follow the appropriate instructions:
if [ "${PATCH_LIBPATH}" = "" ]; then
PATCH_LIBPATH=${BEA_HOME}/patch_weblogic910/profiles/default/native
fi
This definition enables individual servers or domains to override this definition, if there is a need for those servers or domains to point to the patches in a custom patch profile. In this definition, BEA_HOME
represents the BEA Home directory path. You can specify an absolute path, or use an environment variable, such as $BEA_HOME
, which you have previously defined (recommended).
PATCH_LIBPATH
to the beginning of the statement that sets the system library path for your machine. To make this script usable for all the operating systems and hardware architectures supported by BEA products, you can provide individual statements that set the paths for each of those systems. For example: if [ -n "${LIBPATH}" ]; then
LIBPATH=${LIBPATH}:${WL_HOME}/server/native/aix/ppc
else
LIBPATH=${WL_HOME}/server/native/aix/ppc
fi
LIBPATH=${PATCH_LIBPATH}:${LIBPATH}
export LIBPATH
This ensures that library file patches in the default patch profile override existing, same-named files appearing later in the path.
if "%PATCH_PATH%" == "" set PATCH_PATH=%BEA_HOME%\patch_weblogic910\profiles\default\native
This definition enables individual servers or domains to override this definition, if there is a need for those servers or domains to point to the patches in a custom patch profile. In this definition, BEA_HOME
represents the BEA Home directory path. You can specify an absolute path, or use an environment variable, such as %BEA_HOME%
, which you have previously defined (recommended).
PATCH_PATH
to the beginning of the statement that sets the system library path. To make this script usable for all the operating systems and hardware architectures supported by BEA products, you can provide individual statements that set the paths for each of those systems. For example:if "%WL_USE_X86DLL%" == "true" set PATH=%PATCH_PATH%;%WL_HOME%\server\native\win\32;%WL_HOME%\server\bin;%JAVA_HOME%\jre\bin;%JAVA_HOME%\bin;%PATH%;%WL_HOME%\server\native\win\32\oci920_8
This ensures that library file patches in the default patch profile override existing, same-named files appearing later in the path.
![]() ![]() |
![]() |
![]() |