| Oracle® Smart Update Applying Patches to Oracle WebLogic Server Release 3.3.0 Part Number E14143-12 |
|
|
View PDF |
| Oracle® Smart Update Applying Patches to Oracle WebLogic Server Release 3.3.0 Part Number E14143-12 |
|
|
View PDF |
This section includes the following topics:
After you 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 must ensure that those classes are properly inserted into the appropriate classpath; otherwise they do not take effect. Likewise, if a patch contains library files to be inserted into the library path, you must ensure that the paths for those files are properly handled when the server instances or applications by which they are used are started.
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:
Replacements for resources within a product installation
Class files that can be used by a classloading mechanism, such as a classpath and files in an extension directory
Library files that can be included in a library path
Patches that contain library files may not necessarily replace existing files in the target installation. Therefore they must be loaded explicitly by a start script.
Shared archives that must be deployed and referenced by applications
Patch JAR files that update entities referred to as modules
Review the following sections to learn how patches are applied and how Smart Update organizes those patches on your system. Understanding these processes is necessary to determine whether and how your start scripts should be modified:
Patches That Replace Resources For All Applications, Domains, and Servers
Patches That Must Be Deployed and Referenced By Applications
This section also introduces the basic tasks that you must perform to ensure that the patches you apply to your WebLogic domains become effective:
Patches That Replace Resources For All Applications, Domains, and Servers
Patches That Must Be Deployed and Referenced By Applications
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 system. 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
Class files that are loaded into the WebLogic Server system classpath
Class files that are loaded into the classpath of an application that is deployed on WebLogic Server
Library files that are loaded into the library path for WebLogic Server.
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 (a) modify the appropriate WebLogic domain or server start scripts, if necessary, so that they point to the patch and (b) 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 change start scripts for patches that contain replacements for system resources.
Examples of patches that typically contain replacement artifacts include the following:
Resources for Web server plug-ins
Socket multiplexers
Dynamically linked libraries
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, Oracle recommends that you create a backup of any system resource that you plan to replace before applying the patch that replaces it.
Shared archive patches must be explicitly deployed and referenced by applications that require them. If a Shared Archive patch is to be applied to selected applications and not all applications, you must create a custom patch profile for each unique patch level.
When you download a patch from My Oracle Support, a patch container is placed in the patch download directory. A patch container holds the following:
A patch
A patch may contain several files. These files may include
Classes delivered as replacements for classes, with the same name, that are inserted into the WebLogic system classpath at server start time
Native library files to be inserted into the system path
Configuration files.
Metadata about each patch in the patch container
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 system that is maintained by Smart Update. For details, see Structure of the Installation-Level Patch Directories.)
When you apply a patch to a given patch profile, each file in the patch is handled as follows:
If the patch contains a replacement for a system resource, such as a WebLogic Server plug-in module, the existing resource is automatically updated with the replacement.
If the patch contains a patch JAR file, that is, a set of classes to be loaded into a classpath as updates for existing classes with the same names in the target installation, the following events occur:
The patch JAR file is placed in the installation-level patch directory. For a description of this directory, see Structure of the Installation-Level Patch Directories.
Smart Update creates a file, called the patch manifest JAR, which contains pointers to the classes in the patch JAR file. If a patch manifest JAR for the current profile exists, it is updated with pointers to the classes in the patch JAR file. The patch manifest JAR file is described in Patch Manifest JAR Files.
If the patch contains native library files to be loaded into the system library path, through either the PATH or LIBPATH environment variable, Smart Update verifies the existence of a subdirectory called 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 Open Start Script Dialog Box Icons.
After you install the products and run Smart Update, the patch directories are created. Each product (for example, WebLogic Server, Workshop for WebLogic, WebLogic Integration, and WebLogic Portal) has its own patch directory structure (for example, patch_wls1001, patch_wlw1020, patch_wli1020, and patch_wlp1020) under the Middleware home directory.
Note:
Custom profiles have been deprecated as of Smart Update 3.3.0. Oracle recommends that you no longer use custom profiles. Custom profiles increase the complexity of installing installation-wide WebLogic Server patches.
The product-specific patch directory structure provides clean demarcation of patch maintenance on a product basis. It also provides more flexibility for future products to interoperate with separate or common versions of WebLogic Server.
Figure 5-1 shows the structure of the MW_HOME\patch_product directories.
Figure 5-1 Installation-Level Patch Directories
Table 5-1 describes the contents of each patch directory.
Table 5-1 Directories and Files in the Installation-Level Patch Directory
| This directory | Contains |
|---|---|
|
patch_product\backup |
Contains the patch backup manifest, which includes files and information required to restore an earlier patch level on your system. This directory is created when you apply an installation-wide patch that contains files to be placed in the product installation directory. |
|
patch_product\patch_jars |
Patch JAR files, under each product patch directory (for example, A patch JAR file under each product patch directory may contain one or more of:
Note: Patch JAR files containing replacements for system resources are not stored in this directory ( Note: It is good practice to ensure that your system 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. |
|
patch_product\profiles\default |
Directory for the default patch profile. When you apply a patch, one or more of the following subdirectories may be created:
|
|
patch_product\profiles\custom-profile-name |
Directory for a custom patch profile. The directory takes the name of the custom patch profile. For every custom patch profile created, a directory named for the profile is created automatically. Each custom patch profile directory may contain one or more of the following subdirectories:
|
|
patch_product\registry |
Contains information about
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 containing a JAR file called Bug10131320_1032.jar, which contains WebLogic system-level classes, is applied to the default patch profile, Smart Update performs the following tasks:
Adds Bug10131320_1032.jar to the MW_HOME\patch_wls1032\patch_jars directory.
Creates the following file, if it does not exist already:
MW_HOME\patch_wls1032\profiles\default\sys_manifest_classpath\weblogic_patch.jar
In weblogic_patch.jar, adds the following reference to the WebLogic system classes in Bug10131320_1032.jar:
Class-Path: C:\Oracle\Middleware\patch_wls1032\patch_jars\Bug10131320_1032.jar
Updates the patch registry information in the MW_HOME\patch_wls1032\registry directory.
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 started, and the patch is applied to the default patch profile, Smart Update does the following:
Creates the following directory, if it does not exist already:
MW_HOME\patch_wls1032\profiles\default\native
Puts libmuxer.so in the following directory:
MW_HOME\patch_wls1032\profiles\default\native
Updates the patch registry information maintained in the following directory:
MW_HOME\patch_wls1032\registry
When a module patch is applied, whether it is a common module patch or product-specific module patch, Smart Update adds the patch to the MW_HOME\patch_product\profiles\profileName\modules directory. The original module JAR file is not modified. This approach is implemented to limit the scope of applied patch.
For example, if a module patch for WebLogic Event Server contains updated classes to MW_HOME\wlevs20\modules\com.bea.wlevs.processor.monitor_2.0.0.0.jar, and that patch is applied to the default patch profile, Smart Update performs the following tasks:
Creates the following directory, if it does not exist already:
MW_HOME\patch_wlevs20200\profiles\default\modules
Adds the updated com.bea.wlevs.processor.monitor_2.0.0.0.jar in the MW_HOME\patch_wlevs20200\profiles\default\modules directory
Updates the patch registry information in the MW_HOME\patch_wlevs20200\registry directory.
When WebLogic Event Server starts, it uses the patched module located in the MW_HOME\patch_wlevs20200\profiles\default\modules instead of using the original module that still exists in the MW_HOME\wlevs20200\modules directory.
You can assume that your classpath and library path patches are picked up properly when the WebLogic domain servers are started, without your having to modify any start scripts, if:
Your WebLogic domains use the default scripts generated by the Configuration Wizard for starting the Oracle product server instances configured for those domains.
You do not need to limit the scope of a patch to a specific WebLogic domain or server instance.
Under other conditions, however, you must take additional steps to ensure that patches are inserted into the appropriate classpath or library path when the product servers are started. These additional steps are necessary if the environment in which you have applied patches to the products matches either of the following:
To start the servers in your WebLogic domains, you use custom scripts that do not invoke the default commEnv script:
Windows:
WL_HOME\common\bin\commEnv.cmd
UNIX:
WL_HOME/common/bin/commEnv.sh
You need to limit the scope of a patch to a specific WebLogic domain or server, instead of applying it universally to all domains and servers that run on a particular product installation.
This section provides information on the use of scripts, and how to modify start scripts using the Smart Update Start Script Editor. This section also describes custom scripts that you can use to point all WebLogic domains and servers at patches of classpath, extended classpath, and native library files.
Note:
Workshop for WebLogic (10.1 and later releases) does not enable run-time WebLogic Server patches automatically. After applying patches by using Smart Update, you must also specify the patch profile for the run-time WebLogic Server in Workshop IDE. For more information, see the Workshop for WebLogic documentation.
To ensure that a patch is loaded into a classpath or the system library path when a WebLogic Server instance is started, you might 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 changes that you might need to make to your start scripts:
Default Script that Defines Class and Library Paths for All WebLogic Domains and Servers
How Patch Path Variables Are Inserted into Class and Library Paths
About Setting a Patch Path Variable in a Server Start Script
When a WebLogic Server instance is started, 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:
Windows:
WL_HOME\common\bin\commEnv.cmd
UNIX:
WL_HOME/common/bin/commEnv.sh
Note:
In UNIX environments, if you want to run commEnv.sh manually from the command line or invoke it from a custom server startup script, you must use the following syntax:
. WL_HOME/common/bin/commEnv.sh
or
. ./commEnv.sh (if you are already located in the bin directory)
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.
Table 5-2 Patch Path Variables Defined in the commEnv Script
| This variable | Is set to the location of |
|---|---|
|
PATCH_CLASSPATH |
The patch manifest JAR file for the default patch profile ( This JAR file contains references to classes in the patch JAR files to be loaded into the WebLogic system classpath. For example, the default definition in the if "%PATCH_CLASSPATH%" == "" set PATCH_CLASSPATH= %WLS_PATCH_CLASSPATH%;%WLW_PATCH_CLASSPATH% Note: Most patches provided by My Oracle Support are WebLogic system classpath patches referenced by |
|
WEBLOGIC_EXTENSION_DIRS |
The WebLogic extension directory patch manifest JAR file for the default patch profile ( This file contains references to classes in the patch JAR files to be loaded into the classpath of an application deployed on WebLogic Server. For example, the default definition in the if "%WEBLOGIC_EXTENSION_DIRS%" == "" set WEBLOGIC_EXTENSION_DIRS= %BEA_HOME%\ patch_wls1030\profiles\default\sysext_manifest_classpath Note: This variable is reserved for use by 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. Currently, this mechanism for patching deployed applications is not used with WebLogic Server 9.1. |
|
PATCH_LIBPATH (UNIX only) |
The This folder contains files to be loaded into the system library path through the if [ "${PATCH_LIBPATH}" = "" ];
then PATCH_LIBPATH=${BEA_HOME}
/patch_wls1030/profiles/default/native
|
|
PATCH_PATH (Windows only) |
The native folder in the installation-level patch directory for the default patch profile This folder contains files to be loaded into the system path through the if "%PATCH_PATH%" == "" set PATCH_PATH= %BEA_HOME%\patch_wls1030\profiles\default\native |
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 start 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 WebLogic 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 requires you to define one of the patch path variables with which you start your WebLogic Server instances, you must understand the following:
The sequence in which scripts are executed, by default, in a product installation environment. See Sequence in Which Start Scripts Are Executed.
Placeholders for defining patch path variables in the default start scripts produced by the Configuration Wizard. See Placeholders for Defining Patch Path Variables in Default Scripts.
After 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 the script that must be changed and ensure that the correct values are assigned to all required patch path variables for all target server instances.
A default set of scripts are provided to start WebLogic Server instances and to set variables for each WebLogic domain and the Oracle product installation.
These scripts are executed in a specific order, which is determined by the content of each script.
Table 5-3 identifies:
The default set of scripts that are created for a server, WebLogic domain, and product installation
The function of each script
The order in which the scripts are executed
Table 5-3 Default Set of Scripts in a Product Installation
| This script | Performs this function | When Executed |
|---|---|---|
|
In the Windows: startManagedWebLogic.cmd UNIX: startManagedWebLogic.sh |
Starts Managed Servers in the domain. Patch path variables defined in this script are used by all Managed Servers started by the script. |
When a domain is configured with Managed Servers, such as in a cluster, this script is the first one executed by default. This script invokes the |
|
In the Windows: startWebLogic.cmd UNIX: startWebLogic.sh |
Starts WebLogic Server instances in a domain. Patch path variables defined in this script are in effect for all domain servers except for those that are started. For example, if the previously-executed |
If the domain is configured with Managed Servers, this script is invoked, by default, by the The |
|
In the Windows: setDomainEnv.cmd UNIX: setDomainEnv.sh |
Sets the domain-wide environment for starting and running WebLogic Server instances. Patch path variables defined in this script are in effect for all domain servers not otherwise started by the |
By default, this script is invoked by the The |
|
In the Windows: commEnv.cmd UNIX: commEnv.sh |
Sets domain-wide environment for starting and running WebLogic Server instances. Patch path variables defined in this script are in effect for all domain servers not otherwise started by the |
By default, this is the final script that is invoked to define settings for servers that are started and that run on the installation. Note: In UNIX environments, if you want to run . WL_HOME/common/bin/commEnv.sh
or, if you are already located in the bin directory: . ./commEnv.sh |
When you create a WebLogic 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:
The 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 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_wls1001\profiles\MyProfile\sys_manifest_classpath\weblogic_patch.jar
Note:
Custom profiles have been deprecated as of Smart Update 3.3.0. Oracle recommends that you no longer use custom profiles. Custom profiles increase the complexity of installing installation-wide WebLogic Server patches.
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.
The 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.
By minimizing the number of start scripts to which you add patch path variable definitions, you reduce the amount of maintenance required for those scripts if you change or upgrade the maintenance level or version of the installed product.
The specific tasks you must 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 WebLogic domains, and servers running on the product installation, or only for a specific domain, or server in that installation.
If you use custom start scripts, or if you need to limit the scope of a patch to a specific WebLogic domain, server, you must modify your start scripts as follows:
To insert patches into the system classpath or library path for all server instances that run on a product installation, if you use custom start scripts, you must add references to the default patch profile to those scripts.
To limit the scope of a patch to a specific WebLogic domain, or server, you must perform two tasks:
Create a custom patch profile, to which the patches are applied for the domain, or server that runs on a product installation.
Note:
Custom profiles have been deprecated as of Smart Update 3.3.0. Oracle recommends that you no longer use custom profiles. Custom profiles increase the complexity of installing installation-wide WebLogic Server patches.
In the start script(s) for the corresponding WebLogic domain or server, add references to the custom patch profile.
To learn how to modify start scripts so that the class and library path patches you have applied are properly used, see Overview, which provides the following information:
The distinction between patch files that must be dynamically loaded into the system classpath or library path and patches that are automatically in effect installation-wide
Where, on your system, Smart Update places patch file content when you apply a patch
See also About Pointing Start Scripts at Patches, to find out how the default scripts created by the Configuration Wizard automatically insert class and library patches into the system classpath and library path. Understanding this process is important if you need to change your scripts so that they reference class and library patches appropriately.
You must modify your scripts in the following situations:
You do not use the default scripts in your environment.
You need to limit the scope of a patch to a particular WebLogic domain or server start script.
Table 5-4 provides information about changing a start script.
Table 5-4 Changing Start Scripts
| For information about | Read the following topic |
|---|---|
|
Using the Start Script Editor |
|
|
Opening a start script |
|
|
The modifications required for start scripts to reference the class and library path patches that are in effect for all WebLogic 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 that are in effect for a specific WebLogic domain or server |
Chapter 6, "Patching Individual Applications, Domains, or Servers" |
|
Creating a custom patch profile, which you must do before modifying scripts to point a WebLogic domain or server at patches |
The Start Script Editor is a tool, provided by Smart Update, for locating start scripts in your environment and creating definitions for patch path variables in them. Smart Update maintains scripts in multi-product environments with different patch levels as expressed in combinations of default patch profile and custom patch profiles.
Note:
Custom profiles have been deprecated as of Smart Update 3.3.0. Oracle recommends that you no longer use custom profiles. Custom profiles increase the complexity of installing installation-wide WebLogic Server patches.
Accordingly, in the bottom pane, the script snippet shown is also product-specific, and targets myCustomProfile. A different snippet is provided for each type of path. These paths include classpath, WebLogic extended classpath, and native.
SET PATCH_CLASSPATH=%BEA_HOME%\patch_wls1001\profiles\myCustomProfile\sys_manifest_classpath\weblogic_patch.jar SET WEBLOGIC_EXTENSION_DIRS=%BEA_HOME%\patch_wls1001\profiles\myCustomProfile\sysext_manifest_classpath SET PATCH_LIBPATH=%BEA_HOME%\patch_wls1001\profiles\myCustomProfile\native SET PATCH_PATH=%BEA_HOME%\patch_wls1001\profiles\myCustomProfile\native
export PATCH_CLASSPATH=${BEA_HOME}/patch_wls1001/profiles/myCustomProfile/sys_manifest_classpath/weblogic_patch.jar
export WEBLOGIC_EXTENSION_DIRS=${BEA_HOME}/patch_wls1001/profiles/myCustomProfile/sysext_manifest_classpath
export PATCH_LIBPATH=${BEA_HOME}/patch_wls1001/profiles/myCustomProfile/native
export PATCH_PATH=${BEA_HOME}/patch_wls1001/profiles/myCustomProfile/native
This procedure describes the steps for using the Start Script Editor for WebLogic Platform 9.x, ALSB 2.5, and ALSB 2.6. To use the Start Script Editor, complete the following steps:
In Smart Update, select a target installation from the Target Installation panel.
Choose Patches > Start Script Editor.
In the Start Script Editor dialog box:
Choose the patch profile to which the WebLogic domain or server will point. For information about using a custom patch profile to scope a patch to a specific WebLogic domain or server, see Chapter 9, "Best Practices for Distributing Patches."
Choose the product for which you are editing a start script. See Figure 5-3.
Note:
If you select Workshop for WebLogic, your WebLogic domain does not automatically download any of the WebLogic Server patches that might exist in that custom profile.
Open the start script you want to modify.
For detailed instructions, see Opening a Start Script.
Add the appropriate patch path variable definition to your patch profile.
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 Chapter 6, "Patching Individual Applications, Domains, or Servers," to learn how to create a custom patch profile and add pointers to that profile to the start script for a WebLogic domain or server.
If your custom patch profile myCustomProfile contains both WebLogic Server and Workshop for WebLogic patches, and you want all of them to be active in a specific domain, you must first edit the domain start script to include a product-specific tokenized path declaration, similar to the snippets, but modeled on the declarations in setPatchEnv.cmd:
For example:
WLS_PATCH_CLASSPATH= and WLW_PATCH_CLASSPATH=
instead of:
PATCH_CLASSPATH=
You must also include a concatenation statement similar to the one found in setPatchEnv.cmd:
set PATCH_CLASSPATH=%WLS_PATCH_CLASSPATH%;%WLW_PATCH_CLASSPATH%
Repeat this for each path type.
Save the start script.
Note:
When adding a definition of a patch path variable to a start script, ensure 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 way to locate the appropriate start scripts that must 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:
Detect all appropriate scripts that must be modified. If you use the start scripts provided, by default, by the Configuration Wizard, the Start Script Editor can help you find them quickly.
If you have customized your server and domain start mechanisms, you might need to take additional steps beyond working with the Start Script Editor to make all the necessary changes.
Modify start scripts. The Start Script Editor displays scripts and suggests additions to them, but you make the final decisions about which modifications to make and where to save them.
Create backup copies of your start scripts.
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 WebLogic 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-5 are used to guide you to the directory containing the start script you want to modify.
Table 5-5 Open Start Script Dialog Box Icons
| This icon | Marks |
|---|---|
 |
The parent directory, within a WebLogic domain, of the bin subdirectory in which, by default, the scripts you need to change reside. |
 |
A domain subdirectory, such as bin, in which script files reside. To open a subdirectory and display the scripts in it, click this icon. |
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 that you need to change.
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 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 Table 5-6.
| For information about modifying | See the following section |
|---|---|
|
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 bin subdirectory, as Figure 5-4 shows 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 Table 5-7.
| For information about modifying this script to | See the following section |
|---|---|
|
Point to the patches in the default patch profile |
Pointing All Domains and Servers at Patches Through Custom Scripts |
|
Point to the patches in a custom patch profile |
To modify the start script for a particular server in a domain, select the uniquely-named start script for that server in the domain 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 Table 5-8.
Table 5-8 Modifying Start Script
| For information about modifying this script to | See the following section |
|---|---|
|
Point to the patches in the default patch profile |
Pointing All Domains and Servers at Patches Through Custom Scripts |
|
Point to the patches in a custom patch profile |
It is important to ensure 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 WebLogic Domains and Servers, you should modify those scripts as follows:
Define any environment variables that point to the class and library patches applied to the default patch profile
Add these environment variables to the following paths:
WebLogic system classpath
Classpath used by applications deployed on WebLogic Server, as required by a product
Library path
Ensure that you add this functionality of the default commEnv script to your own scripts through any of the following methods:
Centralize, in one script, the code that points to patches in the default patch profile. Then invoke this central script from all start scripts. Oracle recommends this approach because it simplifies the task of maintaining the code that points to patches and minimizes the number of changes that must be made to scripts as your environment changes.
Make a copy, in every start script, of the code that points to the patches you have applied to the default patch profile. By making sure that this code is included in every start script, you guarantee that all servers in your domains point to the patches that have been applied. As you add servers or change the configuration of your environment, however, the task of properly maintaining your start scripts becomes increasingly complex.
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 ensure that the patch JARs are inserted into this classpath properly, you must add, to your start script, the code described in this section.
Add a default definition of the PATCH_CLASSPATH environment variable. For example:
if "%PATCH_CLASSPATH%" == "" set PATCH_CLASSPATH=BEA_HOME\patch_wls1001\profiles\default\sys_manifest_classpath\weblogic_patch.jar
This definition enables individual servers or domains to override this definition, if those servers or domains must point to the patches in a custom patch profile. In this definition, BEA_HOME represents the Middleware home directory path. You can specify an absolute path, or use an environment variable, which you have previously defined (recommended).
Add PATCH_CLASSPATH to the beginning of the statement that sets the WebLogic system classpath. For example:
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
This ensures that classes in the patch JARs override existing, same-named classes appearing later in the classpath.
If your default patch profile contains patch JARs for applications that are deployed on WebLogic Server for a 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_wls1001\profiles\default\sysext_manifest_classpath
Note:
The WEBLOGIC_EXTENSION_DIRS variable is reserved for use by 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 ensure 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 ensure that 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:
Add a default definition of the PATCH_LIBPATH environment variable. For example:
if [ "${PATCH_LIBPATH}" = "" ]; then PATCH_LIBPATH=${BEA_HOME}/patch_wls1001/profiles/default/native
This definition enables individual servers or domains to override this definition, if those servers or domains must point to the patches in a custom patch profile.
Add PATCH_LIBPATH to the beginning of the statement that sets the system library path for your system. To make this script usable for all the operating systems and hardware architectures supported by 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.
Add a default definition of the PATCH_PATH environment variable. For example:
if "%PATCH_PATH%" == "" set PATCH_PATH=%BEA_HOME%\patch_wls1001\profiles\default\native
This definition enables individual servers or domains to override this definition, if those servers or domains must point to the patches in a custom patch profile. In this definition, BEA_HOME represents the Middleware home directory path. You can specify an absolute path, or use an environment variable, which you have previously defined (recommended).
Add the variable 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 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.
WebLogic Server (10.0 and later releases) and OSGi-based products (for example, Oracle Enterprise Repository) incorporate a modular approach for developing and distributing the software. Patches are provided to update such modules.
Note:
OSGi-based products are built on microServices Architecture (mSA) and they use an Open Services Gateway initiative (OSGi)-based framework to manage services that are provided by modules or feature sets.
Modules can be of two types, common and product-specific. Common modules are shared by multiple products and product-specific modules are used only by a product. Smart Update displays a warning message when you attempt to apply a patch for a common module. You can click Yes, if you want to apply a patch to all the products; otherwise, click No. Follow the instructions on the dialog box.
A run-time instance of WebLogic Platform can contain only a single version of a module. Therefore, to ensure that a given module version is patched correctly, all products used together should be patched consistently relative to a module associated with more than one of the products.
In WebLogic Server, module patches are added through classpath, but in OSGi-based products, patches are loaded using an OSGi-based launcher.
Products such as WebLogic Server load modules to run-time containers through the classpath. For more information about loading patches to a classpath, see Classpath, Extended Classpath, and Native Library Patches.
OSGi-based products load modules to run-time containers through the OSGi-based launcher. The launcher determines the necessary modules and the sequence of modules to be loaded at run time. It also determines whether a module is patched for a given product. If a module is patched, the updated version is loaded and used. The scope of a module patch is specific to the product and to the patch profile. This provides the necessary granularity to ensure that a patch is specific to one product and not to all products in the same Middleware home directory.
In an OSGi-based product installation, you can see two directories for modules—common modules (MW_HOME\modules) and product-specific modules (for example, MW_HOME\wlevs20\modules). Figure 5-6 shows the structure of these directories.
Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.
Figure 5-6 Installation-Level Directory Structure for WebLogic Event Server
Native binaries and other artifacts are in effect for all applications, domains and servers, as described in Patches That Replace Resources For All Applications, Domains, and Servers.
This section describes how shared archive patches are deployed and referenced by applications.
Shared archive patches were introduced to support shared libraries, and in particular WebLogic library modules. Unlike other artifacts installed in the product directory, applications can use shared archives by direct name and version references, rather than relying on a well-known location. This implies that a default installation of a shared archive has an installation-wide (or domain-wide) scope until superseded by a custom installation of the same shared archive into a specified profile.
To activate a shared archive patch after application to the default or a custom profile in Smart Update, you must first deploy the patched archive in the affected domain, and potentially modify the application description to make specific reference to it.
Note:
Custom profiles have been deprecated as of Smart Update 3.3.0. Oracle recommends that you no longer use custom profiles. Custom profiles increase the complexity of installing installation-wide WebLogic Server patches.
Shared archive patches can be applied to an entire domain (or all domains running in a given installation) or selected applications in a domain. To affect potentially all domains in an installation, apply the shared archive patch to the default profile in Smart Update.
For more information on this topic, see Default Application of Shared Archive Patches.
To affect only a specific application, you should apply the patch to a custom profile and update the archive references in the application descriptor. This approach would enable you to maintain unique patch profiles for each application that utilizes shared libraries, if necessary.
For more information on this topic, see Activating Shared Archive Patches in Custom Profiles with Application Scope.
When a shared archive patch is applied, it either replaces an entire archive (or installs an entirely new archive) or partially updates the archive (by insertion).
Which operation is used is determined by the patch creator. If you are not sure, contact My Oracle Support.
When you remove a patch, you must undeploy the patch explicitly in addition to perform patch removal using Smart Update.
To learn more about deploying and undeploying shared libraries, see Deploying Applications to Oracle WebLogic Server. To learn more about shared libraries, see Developing Applications for Oracle WebLogic Server.
When a shared archive patch is applied in Smart Update to the default profile, it is treated by the Patch Management System as applicable to the entire installation. Consequently, when you apply a shared archive patch to the default profile, the patch is applied to all custom profiles (if any) as well. Smart Update warns you that the patch will be applied to the entire product installation. If you click Continue, the patch is applied to all profiles.
The actual write location of the patched shared archive is usually relative to the product shared library directory. You may need this information, depending on how you choose to deploy it.
Shared libraries are located under:
WL_HOME/common/deployable-libraries
WL_HOME/portal/lib/modules
WL_HOME/servicebus/lib
WL_HOME/integration/common/lib/installation
Typically, portal-shared archive patches are installed under maintenance/default in the above common and portal shared library directories. Other products may institute differing default patch directory structures. If you need further guidance for a specific patch, consult My Oracle Support.
If the patch is replacing an existing archive and it is already deployed, you just need to restart the server. If the patch contains a new version, or is to be installed under a different directory, you must deploy the patched archive. Deployment can be done using the WebLogic Server console, custom WLST script, or by directly updating config.xml for the target domain.
On successful deployment of the patched archive, it (including the name, specification, and version number) is visible in the WebLogic Server administration console.
If you leave the library module manifest untouched, all references to the library module remain intact and all applications in the domain immediately take advantage of new functionality without additional manual configurations to application descriptors.
In some cases, you may want to control and apply a patch at a certain level to selected applications. To apply a shared archive patch in such a scenario, create a custom profile and apply shared archive patches to that custom profile only.
To distinguish one version of a shared library patch from another and to allow different versions of a shared library to coexist in a single domain, versions can be distinguished by unique names or unique implementation versions, or both.
After applying a shared archive patch to a custom profile in Smart Update, two steps are required to activate it for the application you intend to patch:
Deploy the patch in the custom profile.
Update the application descriptor to reference the specific version of the patched archive.
The steps to deploy the shared archive patch in a custom profile are the same as those for shared archive patches in the default profile, except that in the custom profile case the patch is located in the following directory:
MW_HOME/patch_weblogicversion/profile/custom-profile-name/archives
For example: MW_HOME/patch_wls1001/profile/customProfile
To support a variety of application-scoped patch scenarios, shared archive patches may be configured when they are created to force unique naming or unique versioning, or both, when the patch is installed. Smart Update detects this if the patch is applied to a custom profile, and may modify the archive's extension-name or implementation version, or both, in the archive manifest at that time.
If a patch was created to force a unique name, the patch install process appends the string "-patch_custom-profile-name" to the manifest extension-name.
If a patch was created to force a unique implementation version, the patch install process decrements the version's last digit and appends a digit N where N is the patch profile ID as defined in patch-registry.xml. For example, an implementation version of 9.2.0.1 might become 9.2.0.0.1.
In general, application descriptors (weblogic.xml for WAR and weblogic-application.xml for EAR) do not require a specific version. Instead, they look for the most recent (highest) version. To reference a specific version of a shared library, you must set the Boolean <exact-match> to true.
For example, in the following section of weblogic-application.xml for a 9.2.0.0.1 shared archive patch, note that <exact-match> is set to true.
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <library-ref> <library-name>wlp-tools-admin-app-lib</library-name> <specification-version> 9.2.0 </specification-version> implementation-version> 9.2.0.0.1 </implementation-version> <exact-match> true </exact-match> </library-ref> </weblogic-application>
|
 Copyright © 2001, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|