Installing Maintenance Updates and Service Packs
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Smart Update allows you to point a domain or server at a set of patches that are not necessarily intended for the entire installation by using a custom patch profile.
This section includes the following topics:
By default, when you download and apply patches, those patches are in effect for the entire target installation. Every domain and server that is configured to run from such an installation runs against the patches applied to it. Sometimes, however, individual servers or domains within a production environment need to run at different patch levels. To accommodate this need, Smart Update allows you to point individual domains, servers, or clusters at specific patches that are not necessarily in effect installation-wide.
For example, if you have (a) multiple BEA products installed in a BEA Home directory, and (b) domains that exclusively use only one of those products, BEA recommends that you point those domains at only those patches that have been applied to the specific product used by the domain.
At a high level, the work required to point an individual domain or server at one or more patches that are not intended to be in effect installation-wide can be summarized as a three-step procedure:
Figure 6-1 provides a detailed version of this procedure.
Figure 6-1 How to Point an Individual Domain, Cluster, or Server at a Custom Patch Profile
By default, all patches included in the default patch profile are in effect for all domains and servers in an entire installation. The patches in a custom patch profile, however, can be put into effect for any subset of domains or servers within an installation. As noted in Patches that Are Automatically in Effect for All Domains and Servers, patches that replace system-wide resources cannot be selectively targeted by a subset of domains or servers. Such selective targeting is possible, however, for patches with classes or library files that are loaded through a start script and thereby supersede existing, same-named resources in the system.
The following sections provide background information about how custom patch profiles can be used to patch individual domains and servers:
When you create a domain using the Configuration Wizard, the Configuration Wizard creates the following scripts for the domain:
setDomainEnv
—Script used to set domain-level environment variables, including those used by all servers.startWebLogic
—Start script used by any WebLogic Server instances in the domain that are not Managed Servers.startManagedWebLogic
—Start script used by Managed Servers in the domain, including those in a cluster.Note: For details, see Default Script that Defines Class and Library Paths for All Domains and Servers.
By default, the values of the PATCH_CLASSPATH
, WEBLOGIC_EXTENSION_DIRS
, PATCH_LIBPATH
, and PATCH_PATH
variables provided in the product installation script, commEnv
, are used by all the server instances that run on that installation. If, however, you override these values for any of the variables in a domain-level script, the new values are used only by the WebLogic Server instances that are started by those scripts.
Note: The definition of a given patch variable should reference no more than one patch manifest JAR. If multiple patch manifest JAR files are referenced, unpredictable behavior may occur at run time.
Modifying the definition of a patch path variable in a start script is a convenient way of pointing servers started by that script at the patches included in a custom patch profile. For example, if you want to point a server at the WebLogic system classes in a patch that has been applied to a custom patch profile, you simply add a definition of the PATCH_CLASSPATH
variable to that server's start script, setting the variable to the path of the patch manifest JAR file in the custom patch profile. Similarly, you can point a server or domain at a native library file in a custom patch profile by adding a reference to the directory in the custom patch profile that contains that native file. To add this reference, you add a definition of the PATCH_PATH
or PATCH_LIBPATH
variable to the start script for the appropriate server or domain.
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. But if you use the start scripts that are created, by default, with standard tools such as the Configuration Wizard, and maintain them in the default locations determined by those tools, Smart Update can provide a structured and predictable method of locating the start scripts that need to be modified and suggesting the specific changes that need to be added to those scripts.
Figure 6-2 shows two patch profiles used in an installation: the default patch profile and a custom patch profile. In this figure:
Figure 6-2 Use of a Custom Patch Profile with the Default Patch Profile
The following PATCH_CLASSPATH
variable references the patch manifest JAR file weblogic_patch.jar
, located in the custom profile ProductionServer1
:
set PATCH_CLASSPATH=
%BEA_HOME%\patch_weblogic910\profiles\ProductionServer1
\sys_manifest_classpath\weblogic_patch.jar
When the preceding definition is added to the startWebLogic
script for a given domain, server instances that are started in that domain by that script will load the class files into the WebLogic server classpaths that are referenced by the weblogic_patch.jar
file in the ProductionServer1
custom profile. This classpath loading occurs when the following line in the commEnv
script is subsequently executed (PATCH_CLASSPATH
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
Note: The weblogic_patch.jar
in the ProductionServer1
profile may reference a set of patch JAR files that is entirely different from the set of patch JAR files referenced in the weblogic_patch.jar
of the default patch profile.
If you want a server in a domain, or any domain in an installation, to continue to point at patches in the default patch profile, you do not need to modify the start script for that server or domain as long as you use the default scripts for servers and domains provided by the Configuration Wizard. If, however, you want one or more servers or a domain to point at a custom patch profile, make sure that the start script you modify affects only the targeted servers or the domains.
For information about the sequence in which start scripts are executed, and how particular definitions of patch path variables affect servers started by scripts with patch path variable definitions, see Sequence in Which Start Scripts Are Executed.
This section provides important information about the use of custom patch profiles:
When you want to point a domain or server at a new set of patches you have downloaded, try to apply the patches to an existing patch profile, if possible. If you need to change the set of patches at which a specific domain or server points, change the content of the custom patch profile that contains the patches. This approach is always preferable to creating a new custom patch profile and modifying start scripts so they point to it. Avoid creating a new profile for each patch that you download. By keeping the number the profiles you create to a minimum, you can more efficiently take advantage of the patch validation and dependency checking capabilities built into Smart Update and the BEA Customer Support Repository.
In addition, when you minimize the number of custom profiles you use, you minimize the number of start script modifications that you need to maintain. As a result, the likelihood of introducing errors in your scripts is reduced. In addition, the work required to remove patches is simplified: you simply update the appropriate patch profile; the need to update scripts is minimized.
BEA accommodates a great deal of flexibility in the use of start scripts. BEA does not enforce the use of specific names and locations for start scripts. However, by staying within the default directory structure that the Configuration Wizard creates for a domain, and by retaining the location and structure of the start scripts that are provided, you maximize your ability to rely on Smart Update to locate and generate suggested changes for start scripts that are required when custom profiles are used.
In general, when pointing a domain or server at a custom patch profile, keep in mind the following guidelines:
setDomainEnv
script, rather than each script that starts a server within the domain. When you implement this practice, you minimize the number of start scripts that you need to modify and maintain.Generally, there are no restrictions on the set of patches that can be added to a custom patch profile or removed from it. Patches that affect installation-wide resources, however, are automatically placed in all existing patch profiles for a target installation.
If you remove a patch that affects installation-wide resources from any single patch profile (regardless of whether that profile is the default profile or a custom profile), the patch is automatically removed from all patch profiles. If you have multiple profiles in a target installation, and you try to replace or remove a patch that affects installation-wide resources, Smart Update displays a warning.
To create a custom patch profile, complete the following steps:
Note: When you create a custom patch profile, Smart Update creates a directory for it, using the name you have chosen for the profile. Therefore, to ensure that custom patch profiles can be used with any combination of hardware and operating system supported by BEA Products software, only alphanumeric characters may be used in custom patch profile names.
The following topics provide more information about custom profiles:
Custom patch profiles may contain the following types of patches:
By default, any installation-wide patches that have already been applied to the target installation are automatically included whenever you create a new patch profile. Smart Update gives you the option, however, of creating a patch profile that initially contains no patches.
When you clone the contents of an existing patch profile to create a custom patch profile, only a subset of the patches from the existing patch profile are physically duplicated on disk:
Replacement patches are not duplicated. When a patch replaces a system resource at the time it is first applied, the system resource is not replaced each time the patch is automatically duplicated in a custom patch profile, nor is a duplicate copy made of the patch container that is referenced by a duplicate entry for the patch in the custom patch profile.
Note: Patches that contain replacements for files or other artifacts are automatically applied to the entire installation.
If you want to create a custom patch profile that includes the same patches in an existing patch profile, you can clone the existing profile and then customize it as needed, by adding or removing patches. This technique is convenient for creating custom patch profiles quickly.
Note: Patches that affect installation-wide resources are included in all patch profiles created in a target installation. You cannot remove this type of patch from one profile without removing it from all patch profiles on the target installation. If you attempt to do so, Smart Update displays a warning message.
After you create a custom patch profile, you can add or remove patches to it, just as you added or removed patches from the default patch profile:
When you apply a patch to the target installation, the following events occur:
Note: Although the patch may be validated and applied to the target installation, any patch containing either classes to be loaded into a classpath or native library files to be loaded into a library path does not go into effect until you complete the following procedure: (a) Modify the appropriate domain or server start scripts, if necessary, to point to the patch. (b) Restart the appropriate domains or servers.
If conflicts are detected, the Patch Installation Validation dialog box displays a summary of those conflicts. The patch cannot be applied until the conflicts are resolved. For more information, see Resolving Patch Conflicts.
Note: The listing for this patch in the Downloaded Patches panel of the Get Patches tab is retained.
To delete a custom patch profile, complete the following steps:
When deleting a custom patch profile, keep in mind the following:
To point a domain or server at a custom patch profile you have created, complete the following steps:
PATCH_CLASSPATH
, WEBLOGIC_EXTENSION_DIRS
, PATCH_LIBPATH
, and PATCH_PATH
variables. These definitions reference patches that contain classes and files to be inserted into the system class and library path. However, depending on the content of the custom patch profile, and the specific patch path variables you need to reference, you might need to make different modifications. 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.
The default start script for the WebLogic Server product home directory is WL_HOME
\common\bin\commEnv
. It contains default values for the following variables used for inserting patch files into a classpath or library path:
For details, see Default Patch Path Environment Variables.
If you add definitions for these variables to a server or domain start script, your new definitions override the default definitions, in the commEnv
script, for the corresponding servers or domain. Therefore, whenever you define these variables in a server or domain script, make sure that your new definitions apply to the appropriate server instances.
Also, note the order in which start scripts are executed: once the definition of one of these variables has been set in a script, it is not overridden by any definition in a script that is executed subsequently. For more information, see Sequence in Which Start Scripts Are Executed.
If you use custom scripts in your environment that do not invoke the WL_HOME
\common\bin\commEnv
script, you also need to modify the statements in your scripts that set the class and library paths for your environment so that the environment variables you have defined are properly inserted into statements such as Set WEBLOGIC_CLASSPATH
and Set PATH
.
For example, to set the WebLogic system classpath so that patch JARs in a custom patch profile supersede same-named classes appearing later in the classpath, add the PATCH_CLASSPATH
variable as follows, 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
For more information about pointing custom scripts at patch profiles, see Pointing All Domains and Servers at Patches Through Custom Scripts.
If you use the Node Manager in your domain, and all the patches used in your domain are applied to the default patch profile, the servers started by the Node Manager will run against those patches automatically. If, however, you use custom patch profiles in a domain that is configured to use the Node Manager, you must complete the additional procedure provided in this section.
To ensure that all the Managed Servers in a domain cluster point to patches in the custom patch profile at startup time, complete the following steps:
Use of the script-based version of the Node Manager is not supported for the procedures presented in this section.
nodemanager.properties
file on each machine that hosts a Managed Server in the cluster. Open each such nodemanager.properties
file and make the following changes:StartScriptName
property is set to the WebLogic Server start script used for all server instances in the domain. The default start scripts are operating system-specific:For information about modifying the nodemanager.properties
file, see Using Node Manager to Control Servers in Managing Server Startup and Shutdown.
setDomainEnv
script for the domain (setDomainEnv.cmd
on Windows, setDomainEnv.sh
on UNIX) and define one or more of the patch path environment variables described in Table 6-1.For each file or directory identified in Table 6-1 that is included in the installation-level patch directory of your BEA Home directory (BEA_HOME
\patch_weblogic910
), add a definition to the setDomainEnv
script for the corresponding patch path variable so that the variable points to that file or directory. In Table 6-1, custom-profile
represents the name of the custom patch profile created in the installation-level patch directory.
For example, if your machine hosts a JAR file called BEA_HOME
\patch_weblogic910\profiles\
custom-profile
\sys_manifest_classpath\weblogic_patch.jar
, add a definition of the PATCH_CLASSPATH
variable to the setDomainEnv
script that points to that file.
![]() ![]() |
![]() |
![]() |