Skip navigation.
Downloads | Product Documentation | Support

Installing Maintenance Updates and Service Packs

# Inserting Patches into the System Path

This section includes the following topics:

- Overview
- How Smart Update Organizes Applied Patches
- About Pointing Start Scripts at Patches
- Modifying a Start Script
- Using the Start Script Editor
- Pointing All Domains and Servers at Patches Through Custom Scripts

# Overview

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:

- Verifying the Addition of Patches to the System Path
- Modifying Start Scripts

## Verifying the Addition of Patches to the System Path

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:

- Your WebLogic domains use the default scripts generated by the Configuration Wizard for starting the BEA product server instances configured for those domains.
- You do not need to limit the scope of a patch to a specific domain or server instance.

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:

- 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 or patch set to a specific domain or server, instead of applying it universally to all domains and servers that run on a particular BEA product installation.

## Modifying Start Scripts

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:

- If you need to insert patches into the system classpath or library path for all server instances that run on a BEA product installation, but you use custom start scripts, you need to add references to the default patch profile to those scripts.
- If you need to limit the scope of a patch to a specific domain or server, you need to perform two tasks:

1. Create a custom patch profile, to which the patches are applied for the domain or server that runs on a BEA product installation.
2. In the start script(s) for the corresponding 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 the following sections:

- See How Smart Update Organizes Applied Patches to find out about:

- 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 machine, Smart Update places patch file content when you apply a patch

- See 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 modify your scripts so that they reference class and library patches appropriately. You need to modify your scripts if: (a) you do not use the default scripts in your environment; or (b) you need to limit the scope of a patch to a particular domain or server start script.
- See Using the Start Script Editor to find out how to use Smart Update's Start Script Editor, which simplifies the task of modifying your start scripts.

# How Smart Update Organizes Applied Patches

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
- 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.

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:

- Patches that Must Be Referenced by Start Scripts
- Patches that Are Automatically in Effect for All Domains and Servers
- How Patch Files Are Stored on Your System by Smart Update
- Structure of the Installation-Level Patch Directory

## Patches that Must Be Referenced by Start Scripts

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:

- 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:
(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 Are Automatically in Effect for All Domains and 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:

- 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, BEA also recommends that you create a backup of any system resource that you plan to replace before applying the patch that replaces it.

## How Patch Files Are Stored on Your System by Smart Update

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:

- A patch or patch set

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 boot time
- Native library files to be inserted into the system path
- Configuration files

A patch set is a collection of two or more individual patches, each with its own set of 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 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:

- 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:

1. 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 Directory.
2. 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 already 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 performs the following tasks:

1. 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 Table 5-1.
2. Copies the native library files from the patch into the `native` subdirectory.

## Structure of the Installation-Level Patch Directory

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

Table 5-1 Directories and Files in the Installation-Level Patch Directory

This directory... | Contains...
--- | ---
`backup` | 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_jars` | 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: Classes intended as replacements for classes with the same names in the installation. These classes need to be inserted into the WebLogic system classpath. Classes required by a BEA product. These classes need to be inserted into applications deployed on WebLogic Server. Note: Patch JAR files containing replacements for system resources are not stored in this directory (`patch_jars`). 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.
`profiles` | Directory tree for all patch profiles created for a product installation, containing the following directories: `profiles\default`—Directory for the default patch profile. When you apply a patch, one or more of the following subdirectories may be created: `profiles\default\sys_manifest_classpath`—Holds the patch manifest JAR file named `weblogic_patch.jar`. This file contains references to classes in patch JAR files (in the `patch_jars` directory) that are to be inserted into the WebLogic system classpath. Patch manifest JAR files are described in Patch Manifest JAR Files. (Note: The majority of patches issued by BEA Customer Support are referenced by `weblogic_patch.jar`.) `profiles\default\sysext_manifest_classpath`—Holds the WebLogic extension directory patch manifest JAR file named `weblogic_ext_patch.jar`. This file contains references to classes in patch JAR files that are required by a BEA product and that must be inserted into the classpaths of applications deployed on WebLogic Server based on that product. Patch JAR files referenced by `weblogic_ext_patch.jar` are also stored in the `patch_jars` directory. Note: The `sysext_manifest_classpath` directory is not used by WebLogic Server 9.1. `profiles\default\native`—Holds native library files that are to be inserted into the system library path and that supersede (not replace) existing, same-named libraries in the installation. For details, see Native Library Files. `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: `profiles\`custom-profile-name`\sys_manifest_classpath`—Holds the patch manifest JAR file, `weblogic_patch.jar`, which contains references to classes in patch JAR files inserted into the WebLogic system classpaths for server instances that point to this custom patch profile. `profiles\`custom-profile-name`\sysext_manifest_classpath`—Holds the WebLogic extension directory patch manifest JAR file, `weblogic_ext_patch.jar`, which contains references to classes in patch JAR files in the `patch_jars` directory that are inserted into the classpaths of applications deployed on WebLogic Server instances that point to this custom patch profile. Note: The `sysext_manifest_classpath` directory is not used by WebLogic Server 9.1. `profiles\`custom-profile-name`\native`—Holds native library files that are to be inserted into the system library path for server instances that point to this custom patch profile.
`registry` | Contains information about: All patches that have been applied to the product installation Product installation files that have been replaced by patches This information is used internally by Smart Update to perform tasks such as patch validation.

### Patch Manifest JAR Files

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:

1. Adds `CR99004.jar` to the `BEA_HOME``\patch_weblogic910\patch_jars` directory.
2. Creates the following file, if it does not already exist:

`BEA_HOME``\patch_weblogic910\profiles\default\sys_manifest_classpath\weblogic_patch.jar`

3. In `weblogic_patch.jar`, adds the following reference to the WebLogic system classes in `CR99004.jar`:

`Class-Path: C:\bea\patch_weblogic910\patch_jars\CR99004.jar`

4. Updates the patch registry information in the `BEA_HOME``\patch_weblogic910\registry` directory.

### Native Library Files

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:

1. Creates the following directory, if it does not already exist:

`BEA_HOME``\patch_weblogic910\profiles\default\native`

2. Puts `libmuxer.so` in the following directory:

`BEA_HOME``\patch_weblogic910\profiles\default\native`

3. Updates the patch registry information maintained in the following directory:

`BEA_HOME``\patch_weblogic910\registry`

# About Pointing Start Scripts at Patches

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:

- Default Script that Defines Class and Library Paths for All Domains and Servers
- Default Patch Path Environment Variables
- How Patch Path Variables Are Inserted into Class and Library Paths
- About Setting a Patch Path Variable in a Server Start Script

## Default Script that Defines Class and Library Paths for All Domains and Servers

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:

Windows:

`WL_HOME``\common\bin\commEnv.cmd`

UNIX:

`WL_HOME``/common/bin/commEnv.sh`

## Default Patch Path Environment Variables

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 (`weblogic_patch.jar`)—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 `commEnv` script for Windows is specified as follows: `if "%PATCH_CLASSPATH%" == "" set PATCH_CLASSPATH= %BEA_HOME%\patch_weblogic910\profiles\default \sys_manifest_classpath\weblogic_patch.jar` Note: Most patches provided by BEA Customer Support are WebLogic system classpath patches referenced by `PATCH_CLASSPATH`.
`WEBLOGIC_EXTENSION_DIRS` | The WebLogic extension directory patch manifest JAR file for the default patch profile (`weblogic_ext_patch.jar`)—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 `commEnv` script for Windows is specified as follows: `if "%WEBLOGIC_EXTENSION_DIRS%" == "" set WEBLOGIC_EXTENSION_DIRS= %BEA_HOME%\patch_weblogic901\profiles\default \sysext_manifest_classpath` Note: This 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. Currently, this mechanism for patching deployed applications is not used with WebLogic Server 9.1.
`PATCH_LIBPATH` (UNIX only) | The `native` folder in the installation-level directory for the default patch profile—This file contains files to be loaded into the system library path through the `LIBPATH` environment variable. For example, the default definition in the `commEnv` script for UNIX is specified as follows: `if [ "${PATCH_LIBPATH}" = "" ]; then PATCH_LIBPATH=${BEA_HOME}/patch_weblogic901/profiles /default/native fi`
`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 `PATH` environment variable. For example, the default definition in the `commEnv` script for Windows is specified as follows: `if "%PATCH_PATH%" == "" set PATCH_PATH=%BEA_HOME%\patch_weblogic910\profiles \default\native`

## How Patch Path Variables Are 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

## About Setting a Patch Path Variable in a Server Start Script

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:

- The sequence in which scripts are executed, by default, in a BEA 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.

### Sequence in Which Start Scripts Are Executed

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:

- Start WebLogic Server instances
- Set variables for:

- Each domain
- BEA 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, domain, and BEA product installation
- The function of each script
- The order in which the scripts are executed

Table 5-3 Default Set of Scripts in a BEA Product Installation

This script . . . | Performs this function . . . | When Executed
--- | --- | ---
In the `bin` directory of your domain: 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 `startWebLogic` script.
In the `bin` directory of your domain: 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 already started. For example, if the previously-executed `startManagedWebLogic` script contains patch path variable definitions for Managed Servers, then the patch path variable definitions appearing in the `startWebLogic` script are overridden for Managed Servers started by the `startManagedWebLogic` script. | If the domain is configured with Managed Servers, this script is invoked, by default, by the `startManagedWebLogic` script. The `startWebLogic` script invokes the `setDomainEnv` script.
In the `bin` directory of your domain: Windows: `setDomainEnv.cmd` UNIX: `setDomainEnv.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 `startManagedWebLogic` script, `startWebLogic` script, or other server-specific script.. | By default, this script is invoked by the `startWebLogic` script. The `setDomainEnv` script contains an invocation to the `commEnv` script to define settings for the domain that are not otherwise defined in the server start scripts or in the `setDomainEnv` script.
In the `WL_HOME``\common\bin` directory of your installation: 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 `startManagedWebLogic` script, `startWebLogic` script, or other server-specific script. | By default, this is the final script that is invoked to define settings for servers that are started and that run on the installation.

### Placeholders for Defining Patch Path Variables in Default Scripts

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:

- 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 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.

- 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 you need to perform with those scripts if you change or upgrade the maintenance level or version of the BEA product software installed.

# Modifying a Start Script

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.

For information about . . . | Read the following topic . . .
--- | ---
Using the Start Script Editor | Using the Start Script Editor
Opening a start script | Opening a Start Script
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 | Patching Individual Domains or Servers.
Creating a custom patch profile, which you must do before modifying scripts to point a domain or server at patches | Creating a Custom Patch Profile

# Using the Start Script Editor

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:

1. In Smart Update, select a target installation from the Target Installation panel.
2. Choose the Patches—> Start Script Editor menu option.
3. In the Start Script Editor dialog box:

1. Choose the patch profile to which the domain or server will point. For information about using a custom patch profile to scope a patch to a specific domain or server, see Patching Individual Domains or Servers.
2. Open the start script you want to modify.

For detailed instructions, see Opening a Start Script.

3. 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 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.

4. Save the start script.

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:

- Detect all appropriate scripts that need to 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 may 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.

## Opening a Start Script

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.

Table 5-4 Open Start Script Dialog Box Icons

This icon... | Marks...
--- | ---
| The parent directory, within a domain, of the `bin` subdirectory in which, by default, the scripts you need to modify reside.
| A domain subdirectory, such as `bin`, in which script files reside. To open a subdirectory and display of 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 you need to modify.

For information about locating a specific start script to modify, see the following topics:

- Modifying the Domain Start Script
- Modifying the Start Script for All Managed Servers or Cluster
- Modifying the Start Script for a Specific Server

### Modifying the Domain Start Script

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.

For information about modifying . . . | See the following topic . . .
--- | ---
The placeholders for definitions of the `PATCH_CLASSPATH`, `PATCH_LIBPATH`, and `PATCH_PATH` variables | 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 | Pointing Domains and Servers at a Custom Patch Profile

### Modifying the Start Script for All Managed Servers or Cluster

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.

For information about modifying this script to . . . | See the following topic . . .
--- | ---
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 | Pointing Domains and Servers at a Custom Patch Profile

### Modifying the Start Script for a Specific Server

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.

For information about modifying this script to . . . | See the following topic . . .
--- | ---
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 | Pointing Domains and Servers at a Custom Patch Profile

# Pointing All Domains and Servers at Patches Through Custom Scripts

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:

- 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 BEA product
- Library path

Make sure 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. This approach is recommended because it simplifies the task of maintaining the code that points to patches and minimizes the number of changes that need to 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.

## Pointing Domains and Servers at Patch JARs in the Default Patch Profile for the WebLogic System Classpath

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.

1. Add a default definition of the `PATCH_CLASSPATH` environment variable. For example:

`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).

2. 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 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.

## Pointing Domains and Servers at Library Patches in the Default Patch Profile

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:

- For UNIX Systems
- For Windows Systems

### For UNIX Systems

1. Add a default definition of the `PATCH_LIBPATH` environment variable. For example:

`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).

2. Add `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.

### For Windows Systems

1. Add a default definition of the `PATCH_PATH` environment variable. For example:

`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).

2. 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 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.