Oracle® Smart Update

Installing Patches and Maintenance Packs

Release 3.2.1

E14143-06

April 2010

This document describes how to use the Smart Update tool to download and apply patches and maintenance packs.

Oracle Smart Update Installing Patches and Maintenance Packs, Release 3.2.1

E14143-06

Copyright © 2001, 2010, Oracle and/or its affiliates. All rights reserved.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications which may create a risk of personal injury. If you use this software in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of this software. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software in dangerous applications.

Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

This software and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Contents

Preface

- Documentation Accessibility

- Conventions

1 Introduction

- Products Supported by Smart Update Version 3.2.1

- Quick Reference Information

- How Smart Update Simplifies Patch and Maintenance Pack Management

- Features for Downloading and Applying Patches

- Direct Connection to My Oracle Support

- Patch Validation and Conflict Checking

- Command-Line Interface

- Support for Distributed Patching

- Support for Patching Machines That Cannot Connect to My Oracle Support

- Simplified Maintenance Rollback

- Scoping a Patch to Specific Applications, Domains, or Servers

- Features for Installing Maintenance Pack Updates

- Easy-to-Use Graphical Interface

- Listing of Available Maintenance Packs

- Downgrade Capability

- Register for Security Updates

- Resources Available from My Oracle Support

- Overview of Applying Maintenance Patches

- Providing Maintenance to Distributed Machines

- Maintaining Machines that are not Connected to My Oracle Support

- Patching New Versions of Smart Update Manually

- Overview of Installing Maintenance Pack Updates

2 Starting Smart Update

- Before You Start

- Designating the Patch Download Directory

- Obtaining Required Access

- How to Start Smart Update

- Logging In to Smart Update

- Related Topics

- Obtaining a My Oracle Support Account

- Working Offline

- Setting Preferences

- Choosing a Patch Download Directory

- Displaying Patch Sets in the Downloaded Patches Panel

- Setting HTTP Proxy Information

- Related Topics

3 Downloading and Applying Patches

- Choosing a Target Installation

- Specifying Other Middleware Home Directories

- Downloading Private Patches

- Downloading Publicly Available Patches

- Validating Patches Before Downloading

- When Validation Before Downloading is Recommended

- Validation Process

- Using the Patch Download Validation Dialog Box

- Refreshing the View of Patches and Patch Sets

- Viewing Patch Information

- How to Display Patches

- Displaying a List of Publicly Available Patches

- Displaying the Contents of the Patch Download Directory

- About Patches Displayed in the Get Patches Tab

- Viewing Patch and Patch Set Details

- Viewing Details about Patches

- Viewing Details About Patch Sets

- Viewing Currently Downloaded Patches

- Applying and Managing Patches

- About the Manage Patches Tab

- About Patch Profiles

- Applying a Patch to the Target Installation

- Removing a Patch or Patch Set from the Target Installation

- Resolving Patch Conflicts

- Validation When Downloading Patches

- Validation When Applying Patches

- Validation When Removing Patches

- Creating and Using Maintenance Snapshots

- Applying a Patch to the Client

4 Downloading and Installing Maintenance Packs

- Overview

- Using the Node Manager in a Clustered Environment

- Removing Pointers to Custom Patch Profiles

- Viewing Available Maintenance Packs

- Applying the Selected Maintenance Pack

- Upgrading Web Server Plug-Ins

5 Activating Applied Patches in Your Installations and Applications

- Overview

- Patches That Must Be Referenced By Start Scripts

- Patches That Replace Resources For All Applications, Domains, and Servers

- Patches That Must Be Deployed and Referenced By Applications

- How Patch Files Are Stored on Your System By Smart Update

- Structure of the Installation-Level Patch Directories

- Patch Manifest JAR Files

- Native Library Files

- Module Patch Files

- Classpath, Extended Classpath, and Native Library Patches

- About Pointing Start Scripts at Patches

- Default Script that Defines Class and Library Paths for All WebLogic 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

- Modifying a Start Script

- Using the Start Script Editor

- Script Snippet for Windows

- Script Snippet for UNIX

- Opening a Start Script

- Modifying the Domain Start Script

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

- Modifying the Start Script for a Specific Server

- Pointing All Domains and Servers at Patches Through Custom Scripts

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

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

- For UNIX Systems

- For Windows Systems

- Module Patching

- Module Patching in WebLogic Server

- Module Patching in OSGi-Based Products

- Native Binaries and Other Artifacts Patches

- Shared Archive Patches

- Overview

- Archive Replacement Compared with Insertion

- Patch Removal

- For More Information

- Default Application of Shared Archive Patches

- Activating Shared Archive Patches in Custom Profiles with Application Scope

- Updating Application Descriptors

6 Patching Individual Applications, Domains, or Servers

- About Patching Domains or Servers

- About Patching Applications, Domains, or Servers

- How Custom Profiles Can Patch Individual Domains, Servers, and Applications

- How a Domain or Server Can Point to a Patch in a Custom Profile

- Example Use of PATCH_CLASSPATH to Point a Server at Patch Classes

- Pointing to Custom Patch Profiles in OSGi-based Products

- Best Practices for Using Custom Patch Profiles

- Avoiding Proliferation of Custom Profiles

- Modifying Domain and Server Start Scripts

- Removing Patches That Affect Installation-Wide Resources

- Creating a Custom Patch Profile

- Related Topics

- Initial Contents of a Custom Patch Profile

- Cloning a Patch Profile

- Adding Patches to a Custom Patch Profile

- Deleting a Custom Patch Profile

- Pointing Domains and Servers at a Custom Patch Profile

- Important Note if You Use Custom Scripts

- Related Topics

- Managing Custom Patch Profiles in a Node Manager Environment

7 Uninstalling Maintenance Packs and Patches

- Important Note about Uninstalling Products

- Removing a Patch or Patch Set

- To remove a patch or patch set, complete the following steps:

- Uninstalling a Maintenance Pack

- Updating the Embedded LDAP Schema

8 Using the Command-Line Interface

- About the bsu Command

- bsu Command Reference

- Command-Line Interface Examples

- Installation Example

- View Patches Example

- Another View Patches Example

- Display Maintenance Snapshot

- Report of Applied Patches

9 Best Practices for Distributing Maintenance Updates

- Distributing Maintenance Patches to a Production Environment

- Using Smart Update Scripts to Promote a Standard Maintenance Level to a Production Environment

- Creating and Distributing an Archive of the Product Installation

- Providing Patches to Systems that Cannot Connect to My Oracle Support

- Patching an Offline System Through a Shared Patch Download Directory

- Requirements

- Steps

- Patching an Offline System Through Removable Media

- Requirements

- Steps

- Additional Means for Patching an Offline System

10 Known Limitations in Smart Update

- General Issues and Workarounds

- Smart Update 3.1 Exits with an Error if Version Strings of Products that are Not Supported by Smart Update are Present in the Registry

- Smart Update Does Not Run on Apple Macintosh Machine

- Exceptions are Thrown When You Use Smart Update with Node Manager Running

- Patch Application Does Not Enforce Product Check in Command-line Mode

- Invalidated Patches List Other Invalidated Patches as Their Replacement

- The Patch Profile Maintenance Snapshot Is Poorly Formatted When Viewed in Notepad

- Smart Update Graphical User Interface Displays an Exception in Rare Cases

- Uninstall Component Does Not Remove Component Patches Automatically

- GUI Cannot Refresh Patches Installed from Command Line Without Restart

- Issues with Domains Created After Rollback from WebLogic Server 10.3.2 to 10.3.1

- Downgrade Option is Unavailable in Smart Update After Upgrade to WebLogic Server 10.3.2

11 Frequently Asked Questions

- How do I get a Support ID?

- What is a Bug or CR?

- How can I get a fix to a bug? Can I get a patch for a bug?

- How do I obtain security advisory notifications?

- What is a private patch?

- How do I get the ID for a private patch?

- How do I download just a maintenance pack?

- What products can I patch using the Smart Update tool?

- Do I need a support contract to download patches from My Oracle Support?

A Smart Update Quick Reference

- How to Download and Apply a Private Patch

- How to Generate a Maintenance Snapshot

- How to Create a Custom Patch Profile

- Smart Update GUI Glossary

Glossary

Preface

This preface describes the document accessibility features and conventions used in this guide–Oracle Smart Update Installing Patches and Maintenance Packs.

Documentation Accessibility

Our goal is to make Oracle products, services, and supporting documentation accessible to all users, including users that are disabled. To that end, our documentation includes features that make information available to users of assistive technology. This documentation is available in HTML format, and contains markup to facilitate access by the disabled community. Accessibility standards will continue to evolve over time, and Oracle is actively engaged with other market-leading technology vendors to address technical obstacles so that our documentation can be accessible to all of our customers. For more information, visit the Oracle Accessibility Program Web site at http://www.oracle.com/accessibility/.

Accessibility of Code Examples in Documentation

Screen readers may not always correctly read the code examples in this document. The conventions for writing code require that closing braces should appear on an otherwise empty line; however, some screen readers may not always read a line of text that consists solely of a bracket or brace.

Accessibility of Links to External Web Sites in Documentation

This documentation may contain links to Web sites of other companies or organizations that Oracle does not own or control. Oracle neither evaluates nor makes any representations regarding the accessibility of these Web sites.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/support/contact.html or visit http://www.oracle.com/accessibility/support.html if you are hearing impaired.

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

1 Introduction

This section contains the following topics:

- Products Supported by Smart Update Version 3.2.1

- Quick Reference Information

- How Smart Update Simplifies Patch and Maintenance Pack Management

- Register for Security Updates

- Resources Available from My Oracle Support

- Overview of Applying Maintenance Patches

- Overview of Installing Maintenance Pack Updates

Products Supported by Smart Update Version 3.2.1

By using Smart Update, you can obtain patches and maintenance packs for the following products:

- Oracle WebLogic Server 9.1, 9.2, 10.0, 10.3.x

- Oracle Workshop for WebLogic 9.2, 10.0, 10.1, 10.2, 10.3.x

- Oracle Workshop for JSP 10.1, 10.2

- Oracle WorkSpace Studio 1.1

- Oracle WebLogic Integration 9.2, 10.2, 10.3

- Oracle WebLogic Portal 9.2, 10.0, 10.2, 10.3

- Oracle WebLogic Event Server 2.0

- Oracle Complex Event Processing 10.3

- Oracle WebLogic Operations Control 1.0, 10.3

- Oracle Communications Converged Application Server 4.0

- Oracle Communications Services Gatekeeper 4.0

- Oracle Service Bus 2.1, 2.5, 2.6, 3.0, 10.3

- Oracle AquaLogic Data Services Platform 3.2

- Oracle AquaLogic Enterprise Repository 3.0

Note:
Service packs are replaced by maintenance packs starting with WebLogic Platform 9.2 Maintenance Pack 1.

Quick Reference Information

To start using Smart Update right away, refer to the sections listed in Table 1-1. These sections summarize the steps required to perform basic Smart Update tasks.

Table 1-1 Smart Update Quick Reference Information

Quick Reference Information

Contents

How to Download and Apply a Private Patch

Procedure for downloading and applying a private patch created for you by My Oracle Support.

How to Generate a Maintenance Snapshot

Procedure for creating a maintenance snapshot, a simple text file containing detailed information about the maintenance level of the product installation. This file is requested by My Oracle Support whenever you contact them for assistance.

How to Create a Custom Patch Profile

Procedure for creating a custom patch profile, which you use to point an individual WebLogic domain or one or more servers at patches that are not intended to be in effect for all servers that run on the product installation.

Smart Update GUI Glossary

Definitions of the icons and labels used in the Smart Update graphical interface.

bsu Command Reference

Reference for the bsu command, the Smart Update command-line interface to Smart Update.

How Smart Update Simplifies Patch and Maintenance Pack Management

Smart Update is a standalone Java application that you can run independently of any software to upgrade the software installations quickly and easily with maintenance patches and maintenance packs.

For more information about the products that Smart Update supports, see Products Supported by Smart Update Version 3.2.1.

When you install a product for the first time, Smart Update is automatically installed in your Middleware home directory.

Smart Update is enhanced from time to time with new features, and is made available on the download server.

The new version of Smart Update is placed on the download server. If you log in using an earlier version of Smart Update, the latest version is pushed to your machine, and it is installed automatically.

After the installation, you are prompted to close and start Smart Update again. Click Yes to start Smart Update, and proceed to download patches, or click Cancel if you do not want to proceed with downloads at that point.

When you start Smart Update at a later point, the updated version is invoked.

The following sections summarize the main features of the Smart Update program:

- Features for Downloading and Applying Patches

- Features for Installing Maintenance Pack Updates

Features for Downloading and Applying Patches

Smart Update delivers a set of robust features that simplify the process of installing, or applying, maintenance patches to the product installations:

- Direct Connection to My Oracle Support

- Patch Validation and Conflict Checking

- Command-Line Interface

- Support for Distributed Patching

- Support for Patching Machines That Cannot Connect to My Oracle Support

- Simplified Maintenance Rollback

- Scoping a Patch to Specific Applications, Domains, or Servers

Direct Connection to My Oracle Support

When you start Smart Update, you are prompted to log in to My Oracle Support using your My Oracle Support ID and password. (For information on obtaining a My Oracle Support account, see Obtaining a My Oracle Support Account.) After logging in, you can access private and publicly available patches:

- A private patch is one that My Oracle Support makes available to you as part of a custom maintenance solution, or that otherwise is not generally available from the My Oracle Support repository. You retrieve a private patch after you provide the patch ID and passcode given to you by My Oracle Support.

- A publicly available patch is one that My Oracle Support makes generally available to anyone who has a My Oracle Support login ID. Smart Update displays a panel from which you can view information about publicly available patches that you can download. When you select a specific product installation in your Middleware home directory, Smart Update displays a list of publicly available patches specific to the version and maintenance level of that installation. You can click on the entry for any publicly available patch in this listing to obtain detailed information.

Multiple patches are bundled into a single patch set, which simplifies the process of downloading and applying a related set of patches, and also helps ensure that the patches within each set are applied and managed in the proper sequence.

Patch Validation and Conflict Checking

Each patch created for a particular maintenance level of a product is validated against all existing patches for that maintenance level. When you run Smart Update to view and download patches, you automatically leverage the validation data provided by My Oracle Support to eliminate the chances of applying a patch with a known conflict with any other patch that has been properly applied to the product installation.

For example, when you attempt to apply one patch that depends on another that has not been applied, Smart Update notifies you of the dependency. You can then download the prerequisite patch and apply it before proceeding. Patch validation is performed automatically whenever you apply a patch. You also have the option of requesting patch validation before downloading a patch.

Occasionally My Oracle Support may provide a replacement for a patch, or invalidate a patch, that you have previously downloaded and applied. If this happens, the first time you log in after the replacement becomes available, or the patch has become invalidated, Smart Update automatically notifies you. The patch you previously downloaded or applied is then marked invalidated in the patch listing in the Smart Update graphical interface. Information about obtaining the replacement patch, when available, is also provided.

Command-Line Interface

A command-line interface to Smart Update enables you to apply patches and obtain information about patches that have been downloaded or applied. You can perform these functions directly, from the command line, or indirectly, by writing scripts that include Smart Update commands.

Note:
The command-line interface does not include the ability to connect to My Oracle Support. Therefore, it cannot be used to download patches.

Support for Distributed Patching

Smart Update supports a model in which patches that you have downloaded to a central location in an organization can be distributed through a script to machines in a production environment on which products have been installed. This model enables you to adapt Smart Update to your business practices that govern how maintenance updates are distributed and applied to machines, especially those in a production environment from which a direct connection to My Oracle Support for downloading patches is not appropriate or possible.

Support for Patching Machines That Cannot Connect to My Oracle Support

Smart Update does not require each machine being updated to connect directly to My Oracle Support or to the internet. Smart Update can be used in GUI or command-line mode to apply, remove, and view patches and patch information.

At least one Internet-connected machine is required for downloading patches and these can be made available to offline machines within the enterprise.

Smart Update Client

When a new version of Smart Update is available on a connected machine, Smart Update applies the new version to itself.

For offline machines, the updated Smart Update installers that apply the new version are provided free.

Patches and the Patch Catalog

On connected machines, Smart Update always updates its catalog when connected to the download server.

For offline machines, you must include an updated catalog manually from a connected machine when copying patches.

You can obtain and apply patches as follows:

- Download patches to the connected machine, and then copy them to a location that can be accessed by the offline machines.

- Run Smart Update in offline mode and apply patches and patch sets that have been made available by other means, such as e-mail, FTP, or physical media delivery.

Maintenance Packs

On connected machines, maintenance packs can be downloaded and installed.

For offline machines, you must acquire an Upgrade installer from My Oracle Support.

For more information about support for offline machines, see Maintaining Machines that are not Connected to My Oracle Support.

Simplified Maintenance Rollback

Smart Update makes it easy to remove patches or patch sets that have been applied, enabling you to restore earlier maintenance levels accurately and reliably:

- As part of its patch validation process, Smart Update notifies you whenever My Oracle Support issues a patch that supersedes an earlier one that you have applied.

- Smart Update automatically notifies you of any patch in your download directory that is superseded or deprecated. If you have applied such a patch, Smart Update highlights the entry for it in the list of applied patches, and marks it as invalidated. Information about a replacement patch, if available, is added to the description of the invalidated patch.

Scoping a Patch to Specific Applications, Domains, or Servers

To support complex production environments, Smart Update enables you to point an individual WebLogic domain or server at a patch or patch set that is not automatically in effect installation-wide; for example, a patch for the WebLogic system classpath that you want to use only in a single test domain. Using this feature is recommended if you have multiple products installed in a given Middleware home directory, and your WebLogic domains are based on specific products.

For example, if you have a domain that is based on Oracle Service Bus, you should scope any Oracle Service Bus classpath patches to only that domain. This way, servers in other domains that do not use Oracle Service Bus do not run with Oracle Service Bus classes in their classpath.

Similarly, you may also want to apply a patch to only selected applications and not all applications for a given WebLogic domain.

Features for Installing Maintenance Pack Updates

Smart Update provides convenient tools for viewing and installing maintenance pack updates:

- Easy-to-Use Graphical Interface

- Listing of Available Maintenance Packs

- Downgrade Capability

Easy-to-Use Graphical Interface

To view the Maintenance Pack Update component, choose Maintenance Packs > Update from the Smart Update main window. For more information about the Maintenance Pack Update window, see Viewing Available Maintenance Packs.

Listing of Available Maintenance Packs

When you use the Maintenance Pack Update component of Smart Update on machines that are connected to the Internet, a list of currently available maintenance packs is automatically displayed.

Note:
You can view this list without logging in to My Oracle Support. To install a maintenance pack, you must log in.

Downgrade Capability

You can downgrade, or revert, a product installation to a previous maintenance pack. Smart Update displays the names of previously issued maintenance packs for the current product version.

Register for Security Updates

The Smart Update tool displays a dialog in which you can register with My Oracle Support. If you register, Oracle Support notifies you of any security updates that are specific to your installation.

If you want to register for security updates, enter your e-mail address and your My Oracle Support password. If you do not want to register, deselect "I wish to receive security updates via My Oracle Support" and confirm your choice.

For more information about registering your installation with My Oracle Support, see Oracle Configuration Manager Installation and Administration Guide.

Resources Available from My Oracle Support

Customers with a valid My Oracle Support login ID can view and download public patches by logging in to My Oracle Support with the Smart Update tool. Customers can also download private patches and Maintenance Pack updates for Oracle products.

For information about creating a My Oracle Support account, see Obtaining a My Oracle Support Account.

Overview of Applying Maintenance Patches

Smart Update makes it easy to view and install maintenance patches for a target product installation. Smart Update also helps you organize patches by providing a list of the patches available from My Oracle Support and a list of the patches that you have downloaded and applied.

In the main Smart Update window you can view lists of patches on two tabs, the Get Patches tab and the Manage Patches tab:

- The Get Patches tab provides two lists of publicly available patches for the selected product installation. These include a list of patches available for download and a list of those downloaded. Multiple machines can share a single patch download directory.

- The Manage Patches tab displays two lists of patches. These include a list of patches applied to the target product installation and a list of patches that have been downloaded for the target installation and are ready to be applied.

The process of applying patches consists of the following steps:

1. Start the Smart Update tool and log in to My Oracle Support.

2. Select the product installation to which you want to apply patches.

3. Select the patches to apply (for private patches, enter the patch IDs and passcodes).

4. (optional) Validate for conflicts before the patches are downloaded, and resolve conflicts.

5. Download and apply the patches.

6. Validate for and resolve conflicts.

Figure 1-1 illustrates the process of applying patches.

Figure 1-1 Applying Patches

For information about using Smart Update to apply maintenance patches, see Chapter 3, "Downloading and Applying Patches."

Providing Maintenance to Distributed Machines

The command-line interface to Smart Update is especially convenient for maintaining large numbers of distributed machines in a carefully controlled, reliable, and reproducible state. For example, suppose you are involved in the following business scenarios:

- You have a tightly controlled production environment in which you must run multiple installations of products at highly specific maintenance levels.

- The business practices for your IT environment require that software maintenance updates are distributed to all machines from a central, internal source.

An example of using Smart Update command-line interface to apply a specific set of patches to multiple machines consists of the following steps:

1. From one machine, use the Smart Update graphical interface to log in to My Oracle Support to download the required patches.

2. Copy the patches and an updated patch catalog into a location that can be accessed by each machine to which the patches are to be applied.

3. Create a shell script that contains the Smart Update commands for applying those patches.

4. Run the script on each machine on which the products are installed.

Note:
The machine to which maintenance updates are downloaded from My Oracle Support must have a target installation selected that matches the distributed target installations to be updated.

For an example of distributing maintenance to multiple product installations in a production environment, see Chapter 9, "Best Practices for Distributing Maintenance Updates."

Maintaining Machines that are not Connected to My Oracle Support

Under some circumstances, it is not desirable or possible to establish a direct connection from a particular machine to My Oracle Support. For example:

- You urgently need to download and apply a critical patch, but the internet connection for your business is temporarily unavailable due to a system failure.

- You need to provide regularly scheduled maintenance updates to production machines that reside in a DMZ, or behind a firewall, where connecting to My Oracle Support is permanently disabled.

Smart Update supports a variety of methods for providing maintenance updates to such machines. Though Smart Update helps you connect to My Oracle Support to obtain patches, you are not required to get patches in this way. Smart Update also enables you to obtain patches from alternative sources, such as remotely mounted disks or removable media. By taking advantage of this flexibility, you can adapt Smart Update to your organization's IT practices and create a controlled, reliable, and reproducible process for maintaining the product installations.

If your environment includes at least one machine from which you can log in to My Oracle Support, you can obtain and distribute patches to all product installations in your environment that are supported by Smart Update. There is, however, one prerequisite for the machine used to download patches. It must be able to select a target installation that matches the target installation on the other machines to which updates are subsequently made available.

All products on this machine do not need to be deployed, configured, or running, unless you choose, for example, to keep a defined maintenance state current at the download location, to perform preliminary patch conflict validation at download time.

Smart Update can be configured on this machine to download patches to any networked drive or directory. The default directory is MW_HOME\utils\bsu\cache_dir\.

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

For information on downloading patches, see

- Setting HTTP Proxy Information

- Chapter 3, "Downloading and Applying Patches."

For information on applying the patch on the offline machine,

- If using the GUI in offline mode, see Working Offline.

- If using command line, Chapter 8, "Using the Command-Line Interface."

To use the GUI on an offline machine, click Offline in the Log-in dialog.

Patching New Versions of Smart Update Manually

On connected machines, Smart Update patches itself and restarts if a new version is available when a connection is made. See How Smart Update Simplifies Patch and Maintenance Pack Management.

Note:
On offline machines, you can use Smart Update v3.1 to apply patches that are downloaded using Smart Update v3.2.1. Oracle Support does not provide a standalone installer for Smart Update v3.2.

You can view the version number of the Smart Update installation by choosing Help > About from the GUI or by using the -version option in command-line mode. When using Smart Update v3.x or later, you can compare the version on a connected machine and the one on an offline machine, and manually update the offline machine to match the latest version of Smart Update.

If an incompatible version of Smart Update is used to apply a patch, there can be errors. These errors usually do not indicate that the cause is mismatched Smart Update versions. In such cases, My Oracle Support can confirm that there is a mismatch and supply a standalone Smart Update installer. The mismatch can be ascertained from the log files; see About the bsu Command, for information on the -log option.

The standalone installer available from My Oracle Support is updated within 24 hours of an automatic Smart Update patch event. You can use the installer to install either to an empty MW_HOME or to an existing MW_HOME containing installed products. When it is installed in an existing MW_HOME, the installer creates the necessary directories and replaces any existing version of Smart Update.

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

The standalone installer does not touch the contents of the existing cache_dir directory, and should not affect any of the previously downloaded or applied patches. It does not update existing patch-catalog.xml either.

Ensuring Smart Update Matches the Latest Version Used on the Connected Machine

To ensure that you have the latest version of all the required files, copy all the patches and all patch-*.xml files in the download directory, including the patch-catalog.xml from the connected machine to the offline machine.

The default patch download directory is MW_HOME\utils\bsu\cache_dir. This can be changed from the Preference menu or using the parameter patch_download_dir in the command-line mode.

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

The encoded patch catalog, patch-catalog.xml, contains metadata about a patch and the patch dependencies and conflicts. Localized patch catalog files, such as patch-ja.xml, include the information for that particular language (in this case, Japanese.)

In a complete offline environment, contact My Oracle Support to obtain the latest copy of the patches and patch catalogs.

Figure 1-2 illustrates an example of providing maintenance updates to machines that are not connected directly to My Oracle Support.

Figure 1-2 Example of Patching a Machine that is not Connected to My Oracle Support

For more information, see Providing Patches to Systems that Cannot Connect to My Oracle Support.

Overview of Installing Maintenance Pack Updates

Smart Update includes a component called Maintenance Pack Update, which you can use for downloading and installing maintenance packs (patch sets) as they become available for a product that you have installed. By using the Maintenance Pack Update component to install a maintenance pack, you retrieve, from My Oracle Support, only the code and media archives needed for the components currently installed. This customized retrieval optimizes the size of the archive, which makes the download process more efficient.

For offline machines, you must acquire an Upgrade installer from My Oracle Support. See "Downloading an Upgrade Installer From My Oracle Support" in Oracle WebLogic Server Installation Guide.

When installing a maintenance pack, Smart Update creates a backup of the current installation. You can use this backup to restore the system state if you need to roll back a maintenance pack update.

Figure 1-3 summarizes the steps you must complete to install a maintenance pack.

Figure 1-3 Installing a Maintenance Pack

For information about using Smart Update to download and install maintenance packs, see Chapter 4, "Downloading and Installing Maintenance Packs."

2 Starting Smart Update

This section provides the following topics:

- Before You Start

- How to Start Smart Update

- Logging In to Smart Update

- Setting Preferences

Before You Start

Before you begin using Smart Update to download and apply updates to your product installations, read the following topics:

- Designating the Patch Download Directory

- Obtaining Required Access

Designating the Patch Download Directory

The patch download directory is a single-level directory or folder into which patch files are placed when you download them from the download server. Before you start downloading patches, ensure that you have designated a directory to serve this function, as described in this section.

A patch download directory is created automatically the first time you use Smart Update to download a patch, but you may not want to use it in its default location. For example, your organization might encourage or require you to use a particular location for storing maintenance updates that are downloaded from software vendors. This location might be a centralized repository, or a set of cache directories labeled for certain configurations. By taking advantage of the flexibility of Smart Update for storing updates, you can adapt the maintenance download model of Smart Update to business practices in which software maintenance is administered centrally or in which the maintenance image must be replicated easily for promotion to QA, staging, and production environments.

To designate a patch download directory, complete the following steps:

1. Start Smart Update.

Note:
Logging in to My Oracle Support is not necessary.

2. From the main Smart Update window, choose the File > Preferences menu option.
The Preferences dialog box is displayed.

3. In the Patch Download Directory section of the Preferences dialog box, specify the path of the patch download directory.
Note the following information about the patch download directory:

- The directory MW_HOME\utils\bsu\cache_dir is created as the default patch download directory for the current system when you download a patch for the first time.

- Until you specify a different directory, the default patch download directory is used for storing downloaded patches for all products on your system; the directory used for this purpose is not changed when additional Middleware home directories are created.

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

Obtaining Required Access

Before you start using Smart Update, ensure that you have access to all required resources. Specifically:

- Ensure that you have a valid My Oracle Support account and login ID.
For information about obtaining a My Oracle Support account, see Obtaining a My Oracle Support Account.

- Ensure that you have proper write privileges for the patch download directory, particularly if this directory resides on a remote disk drive or computer.

- If you are running Smart Update on a system located behind a firewall, you might need to specify, in the Preferences dialog box, one of two types of information. These are the host name and port number for an HTTP proxy server, or the authentication information required for perimeter security.

- Ensure that you have the privileges required to access the target product installation directories. The ability to access these directories is especially important if you are patching product installations on networked or remotely mounted disk drives.

How to Start Smart Update

Table 2-1 provides instructions for starting the Smart Update graphical interface on Windows and UNIX systems.

Table 2-1 Starting Smart Update

To start Smart Update on this platform

Perform the following steps

Windows

From the Start Menu, choose:

Start > Programs > Oracle WebLogic > Smart Update

Or, from an MS-DOS command prompt window:

1. Go to the MW_HOME\utils\bsu directory, where MW_HOME is the host directory for the product installation that you want to update.
Note: Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

2. At the prompt, enter the following command:

bsu.cmd

The Smart Update login window is displayed.

UNIX

Note: If you want to run Smart Update on a UNIX system, the console attached to the system on which you are upgrading the software must support a Java-based GUI.

1. Log in to the UNIX system.

2. Go to the MW_HOME/utils/bsu directory, where MW_HOME is the host directory for the product installation that you want to update.
Note: Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

3. At the prompt, enter the following command:

bsu.sh

The Smart Update login window is displayed.

Logging In to Smart Update

To establish a connection to My Oracle Support, enter the following information in the Login dialog box:

- Your Support ID

- Your password

Because a connection to My Oracle Support is required for the following operations, the Login dialog box is displayed whenever you:

- Start Smart Update. When you start Smart Update, you are given the option of working offline, that is, without a live connection to My Oracle Support.

- Select the Get Patches tab, if you are not logged in.

- Choose the File > Login menu option.

- Select a maintenance pack to install when using the Maintenance Pack Update component.

Note:
You do not have to log in to install and manage patches that you have downloaded. It is, however, strongly recommended that you log in before you start applying patches so you can validate them with the latest dependency and conflict data. For more information about using Smart Update offline, see Working Offline.

Once you log in, Smart Update establishes an Internet connection to My Oracle Support and provides you with the ability to perform the following tasks for the products installed on your system:

- View publicly available patches and patch sets.

- Download private and publicly available patches and patch sets.

- Download and install maintenance pack updates.

- Validate patches against the latest dependency and conflict data.

Related Topics

- Downloading Private Patches

- Downloading Publicly Available Patches

- Viewing Patch Information

- Chapter 4, "Downloading and Installing Maintenance Packs"

Obtaining a My Oracle Support Account

To obtain a My Oracle Support account, go to the Oracle Support site, http://www.oracle.com/support/index.html, and click My Oracle Support Login.

On the My Oracle Support page, follow the instructions to register as a new user.

Working Offline

You do not need to log in to My Oracle Support to use Smart Update. If you are managing or installing maintenance updates to the product installations, you can work offline.

Note the following:

- The command-line interface to Smart Update does not include the ability to log in to My Oracle Support, so it can be used only in offline mode.

- When you are working offline, Smart Update is not able to validate patches against the latest dependency and conflict data. Therefore, the system from which you log in to Smart Update to obtain patches must be able to reference a target installation that matches the maintenance level of the system from which you apply patches while working offline.

You can initiate an offline Smart Update session in either of the following ways:

- If you are starting Smart Update, click Work Offline in the Login dialog box.

- If you are logged in, choose the File > Logout menu option.

Setting Preferences

From the Preferences dialog box, you can set the following options:

- Location of the patch download directory

- Display mode for patch sets in the Downloaded Patches panel of the Smart Update window

- HTTP proxy or perimeter security authentication information

Choosing a Patch Download Directory

Before you start downloading patches from My Oracle Support, Oracle recommends that you choose an appropriate location to serve as the patch download directory. For more information, see Designating the Patch Download Directory.

Displaying Patch Sets in the Downloaded Patches Panel

Smart Update lets you select a display mode for patch sets shown in the Downloaded Patches panel of the main Smart Update window:

- Choose Display patch sets and all constituent patches if you want to display an entry for each patch in a patch set you have downloaded, and an entry for the patch set itself. (This is the default setting.)

- Choose Hide constituent patches when patch set is present and complete if you want to display only the entry for the patch set that you have downloaded, hiding entries for individual patches that belong to the set.

The second display mode, Hide constituent patches when patch set is present and complete, is in effect only for the Downloaded Patches panel. This setting does not affect the display of patch sets and constituent patches in other locations of the Smart Update interface; namely, in the list of publicly available patch sets in the Get Patches tab, and in the list of patch sets for each profile displayed in the Manage Patches tab.

Setting HTTP Proxy Information

If the system on which you are running Smart Update is located behind a firewall, you might need to specify one of the following options so that you can download patches and install maintenance packs:

- Use HTTP Proxy
Select this option if you want to use an HTTP Proxy server for the download. To use an HTTP Proxy server, you must specify the following settings in Smart Update in Offline mode, before logging into the download server for the first time. Subsequently you do not need to use offline mode to change the settings.

In the Login dialog box, click Work Offline, and specify the following:

- Host—The name or IP address of the proxy server

- Port—The port number of the proxy server
In addition, you might also need to configure the HTTP Proxy Server to allow access to the download servers. Specify the following settings for the HTTP Proxy Server:

- Host—http://pmlb.bea.com

- Port—80

- Host—http://bidslb.bea.com

- Port—80

- Use Authentication
Select this option if the HTTP Proxy server you are using requires server-side authentication. If you select this option, you must specify:

- Username—A valid username required by the proxy server

- Password—A valid password for the user

Related Topics

- Logging In to Smart Update

- Obtaining a My Oracle Support Account

- Working Offline

- Designating the Patch Download Directory

3 Downloading and Applying Patches

This section includes the following topics:

- Choosing a Target Installation

- Downloading Private Patches

- Downloading Publicly Available Patches

- Viewing Patch Information

- Applying and Managing Patches

- Resolving Patch Conflicts

- Creating and Using Maintenance Snapshots

- Applying a Patch to the Client

Choosing a Target Installation

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

To specify which product installation you want to update with Smart Update, you must open the Target Installation panel, shown in Figure 3-1, and highlight the appropriate entry in the list of product installations displayed there.

Figure 3-1 Target Installation Panel

This list identifies the product installations detected by the system on which Smart Update was started. It includes all Middleware home directories that are detected, and all product installations in each directory. The product installation that is currently selected in this list is referred to as the target installation.

The subsequent operations you can perform with Smart Update are specific to the installation you have selected as the target installation. For example:

- The set of patches and maintenance packs that you can obtain from My Oracle Support are specific to the selected target installation. Smart Update prevents you from downloading a patch created for a product other than the one currently selected as the target installation.

- Patch validation—the built-in ability of Smart Update to use the validation data provided by My Oracle Support to eliminate the chances of applying a patch with a known conflict—is specific to this target installation as well.

- The set of patches listed in the patch download directory are specific to the target installation.

Maintenance updates that you apply to one target installation are not applied to any other installation listed in this panel. For example, if you have duplicate installations of one product, either in the same Middleware home directory or in a different Middleware home directory, you can apply maintenance to only one of those installations at a time. (Note that having multiple Middleware home directories on a system is generally not recommended.)

When selecting a target installation, keep in mind the following information:

- The set of Middleware home directories displayed in this panel is not restricted to those detected on the current system. If you have used the current system to install products on remotely mounted disks hosted on other systems, the Middleware home directories for those remote products are displayed as well. This complete listing makes it easy to install maintenance updates on remote systems.

Note:
The Smart Update graphical interface does not detect Middleware home directories created by systems other than the one from which you are running the tool.

- You can install maintenance updates on only one target installation at a time; patches and maintenance pack updates cannot be installed on multiple installations in a single step. You can, however, install multiple updates in a single Smart Update session. After installing maintenance updates in one target installation, you do not have to restart Smart Update before installing updates in another.

- The most recently selected target installation is saved when you exit Smart Update, and is highlighted the next time you start Smart Update. When a single Middleware home directory hosts multiple product installations, you may update those installations in any sequence you like.

- The list of product installations in a Middleware home directory can be expanded or collapsed, as preferred. By default, it is expanded.

- If you are using the command-line interface to Smart Update, be sure to include the -prod_dir=path parameter to set the target installation directory when Smart Update is started. See Chapter 8, "Using the Command-Line Interface."

Specifying Other Middleware Home Directories

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

You can also specify other Middleware home directories—not listed in the Target Installation pane.

Note:
The Middleware home can only be a directory on a local drive, or a locally mounted volume.

If there is no valid installation target, at the time of launching Smart Update, a dialog box is displayed in which you must specify a Middleware home before proceeding.

To specify the Middleware home directory:

1. Choose File > Target Installation > Find Other BEA Home

2. Specify a valid Middleware home directory navigate the hierarchy and select a directory, or type the path in the Location field.

3. Click OK. The new directory is added to the Target Installation pane.

If the directory you specified does not include a valid installation target, an error message is displayed.

Downloading Private Patches

To download a private patch or patch set from My Oracle Support, complete the following steps:

1. Ensure that you are logged in to My Oracle Support.

2. In the Target Installation panel of the main Smart Update window, select a target installation.

3. Select the Get Patches tab.

4. Choose the Patches > Retrieve Private menu option. The View Private Patch dialog box is displayed.

5. In the View Private Patch dialog box, enter the identifier and passcode for the private patch or patch set.

Note:
The identifier and passcode for private patches are available from My Oracle Support.

6. Click Download.

You are prompted to indicate whether you want to check for patch conflicts before downloading the patch. A patch conflict is a validation problem that Smart Update has detected between the patch you have selected to download, apply, or remove and the other patches that have been applied to the target installation. Checking for conflicts before downloading a private patch or patch set is unnecessary unless specifically recommended by My Oracle Support.

Details about private patches are available in the Downloaded Patches panel. Note that no distinction is made, in the Downloaded Patches panel, between private and publicly available patches.

Related Topics

- Viewing Patch and Patch Set Details

- Validating Patches Before Downloading

Downloading Publicly Available Patches

When you are logged in to My Oracle Support, you can download publicly available patches. To download one or more publicly available patches, complete the following procedure:

1. Start Smart Update and log in to My Oracle Support.

2. In the Target Installation panel of the main Smart Update window, select a target installation.

3. Select the Get Patches tab.

4. In the available patches panel, select the check box for each of the patches you want to download.
To learn how to find detailed information about the patches listed in the available patches panel, see Viewing Patch Information.

Note:
Smart Update does not automatically refresh the lists of publicly available and downloaded patches that it displays. To update lists of patches and patch sets, choose Patches > Refresh View.

5. Click Download Selected.

You are prompted to indicate whether you want to check for patch conflicts before downloading the patch.

Validating Patches Before Downloading

When you request the download of a patch from My Oracle Support, Smart Update prompts you to specify whether you want to have conflict checking performed before the requested patches are downloaded. Pre-download validation is recommended only for publicly available patches.

Conflict checking, also known as patch validation, is the process of determining if a patch has a conflict with other patches for the target installation. When you choose to validate a patch before downloading it, Smart Update validates the patch you are downloading against patches that have been applied to the default patch profile for the target installation. If a conflict is detected—for example, the patch you are downloading requires that another patch be applied first—Smart Update reports the conflict. This gives you an opportunity to resolve the conflict before continuing, but does not prevent you from proceeding with the download.

Smart Update always validates patches when you apply them, but pre-download validation of patches is optional. By validating a patch before you download it, however, you reduce the number of conflict resolution tasks that you might need to perform later if you try to apply a patch that conflicts with another.

When Validation Before Downloading is Recommended

Oracle recommends that you validate a patch before downloading it in the following circumstances:

- You are downloading a publicly available patch.

- You have previously applied patches to the target installation.

- You do not have a complete list of the patches currently available in the patch download directory.

- You are downloading a private patch, but My Oracle Support has specifically recommended that you validate it before downloading.

Validating a patch before downloading is not recommended in the following circumstances:

- You are downloading a private patch and My Oracle Support has strongly assured you that the patch has been developed for compatibility with your existing installation.

- The download directory is used by multiple product installations, running at various patch maintenance levels.

- You are downloading patches for a target installation that is not currently accessible from the system on which you are running Smart Update.

- You are downloading a patch for inclusion in a custom patch profile.

If a conflict condition is detected during the validation of a patch before a download, you have the option to take remedial action before the patch is moved to the patch download directory. Although the report of a conflict does not prevent you from downloading a patch, it may prevent you from applying the patch. Therefore, it is good practice to avoid downloading patches that are likely to cause conflicts.

Note:
When you later apply a patch, Smart Update performs another validation automatically. For a comparison of the two types of validation, see Resolving Patch Conflicts.

Validation Process

The validation process for the specified patches begins as soon as you select pre-download validation. Smart Update keeps you informed about the progress of the ongoing process by displaying status messages in a message box.

If, for any reason, you decide to terminate the validation process and return to the Get Patches tab, you can do so by clicking Cancel anytime before the end of the process.

When validation is complete, one of the following dialog boxes is displayed:

- A message box indicating that no conflicts were detected. Click OK to complete the download procedure.

- The Patch Download Validation dialog box, which displays a list of the detected conflicts.

The following section explains how to use the Patch Download Validation dialog box.

Using the Patch Download Validation Dialog Box

In the Patch Download Validation dialog box, the patches that you have selected for download are listed at the top. Note the use of icons in this dialog box, as described in Table 3-1.

Table 3-1 Description of Icons Used in Patch Download Validation Dialog Box

Icon

Description

The corresponding patch or patch set has not generated any conflicts.

The corresponding patch or patch set has generated one or more of the conflict conditions noted in the lower portion of the dialog box.

The first patch that has generated a conflict condition is highlighted in the upper portion of this dialog box; conflicts detected for that patch are summarized in the lower portion. If a conflict condition is not generated for the selected patch, the inapplicable conflict conditions in the lower portion of the dialog box are greyed out. Table 3-2 describes use of the Patch Validation dialog box.

Table 3-2 Using the Patch Validation Dialog Box

To ...

Take the following action

Display conflict information about a patch selected for download.

Select the patch among the list in the upper portion of the dialog box that has generated one or more conflicts, and view the conflict summary in the lower portion.

Obtain more information about the meaning of each conflict and instructions for resolving it.

See Resolving Patch Conflicts.

Cancel the download operation.

Click Cancel.

This cancels the download procedure, allowing you to take specific actions as appropriate before attempting again to download the patches.

Note: Resolving conflicts in a patch before you download it is generally recommended, subject to exceptions described in When Validation Before Downloading is Recommended.

Proceed with the download operation anyway.

Click Download All.

Note: The patch is not applied; it is simply moved into the patch download directory.

Download only patches that do not generate conflicts.

1. Click Cancel.

2. In the Get Patches tab, add only the patches that do not generate conflicts, and download them.

To find out how to resolve reported patch conflicts before downloading patches, see Validation When Downloading Patches.

Refreshing the View of Patches and Patch Sets

The lists of patches and patch sets shown in the Get Patches tab and the Downloaded Patches panel are not automatically refreshed by Smart Update when patches are added to or removed from the patch download directory. To refresh these lists, choose Patches > Refresh View.

Viewing Patch Information

Smart Update offers you the option of reading detailed information about a patch before applying it. Specifically, Smart Update provides this option for patches in two categories. These categories are those that are publicly available for download from My Oracle Support and those that have been downloaded by you, either to your system or to a networked disk drive that you can access.

Note:
To obtain a list of patches that are publicly available for download, you must be logged in to My Oracle Support.

The following sections explain how to use Smart Update to obtain information about available patches:

- How to Display Patches

- About Patches Displayed in the Get Patches Tab

- Viewing Patch and Patch Set Details

- Viewing Currently Downloaded Patches

How to Display Patches

This section explains how to display lists of the following types of patches:

- Patches that are publicly available from My Oracle Support for the target installation

- Patches that have been downloaded to the current patch download directory

Note:
Private patches are not generally viewable the same way as publicly available patches. However, after you have downloaded a private patch, you may view details about that patch in the same way as other patches you have downloaded. For more information about obtaining private patches, see Downloading Publicly Available Patches.
The patch download directory is specified in the Preferences dialog box, as explained in Choosing a Patch Download Directory.

Displaying a List of Publicly Available Patches

1. In the Target Installation panel, select the desired target installation. For details, see Choosing a Target Installation.

2. Select the Get Patches tab. If you are not logged in when you select this tab, Smart Update prompts you to log in.

Note:
You cannot view the Get Patches tab if you are not logged in.

If you are logged in, the list of available patches is displayed in the upper panel of the Get Patches tab. For details about the information displayed in this panel, see About Patches Displayed in the Get Patches Tab.

Displaying the Contents of the Patch Download Directory

For a list of the patches currently residing in the patch download directory, check one of the following tabs in the main Smart Update window:

- The Get Patches tab shows the contents of the patch download directory for the target installation.

- The Manage Patches tab lists two categories of patches in the download directory:

- Patches that have been applied to the target installation through the currently selected patch profile. Patch profiles are described in About Patch Profiles.

- Patches that have not been applied to the target installation within the context of the currently selected patch profile. Patches in this category are listed in the Downloaded Patches panel of the Manage Patches tab for the current patch profile.

For an explanation of the information displayed in the Downloaded Patches panel, see Viewing Currently Downloaded Patches.

You can also view lists of patches that have been downloaded into a directory other than the current patch download directory by specifying the desired directory in the Preferences dialog box. For more information, see Downloading Publicly Available Patches.

About Patches Displayed in the Get Patches Tab

The Get Patches tab includes two panels:

- The upper panel shows patches and patch sets publicly available for download

- The lower panel shows patches and patch sets downloaded for the target installation highlighted in the Target Installation panel.

The Get Patches tab also gives you the option to request detailed information about any patch listed in either panel.

Which patches and patch sets are listed as publicly available for download is determined by the maintenance level of the target installation. Only patches created for the current maintenance level of the target installation are included.

The top panel of the Get Patches tab displays lists for two categories of patches and patch sets:

- Critical—Patches that My Oracle Support strongly recommends you apply immediately to protect the integrity of data and applications, such as patches related to security bulletins.

- Optional—Patches that improve a product feature that you may or may not be using.

For your convenience, Smart Update enables you to expand and collapse both lists.

Note:
Smart Update does not automatically refresh the lists of publicly available and downloaded patches. To update the lists of patches and patch sets, choose Patches > Refresh View.

Table 3-3 describes the information displayed in each column of the top panel of the Get Patches tab.

Table 3-3 Information about Patches Available for Download

Column Title

Description

Patch ID

The patch identifier is a unique string, associated with either an individual patch or patch set, that is downloaded as a single entity.

One of the following icons is displayed beside the patch identifier: Indicates a single, discrete patch that can be applied to a target installation. Indicates a patch set, which is a group of patches that can be applied to a target installation in a single operation. The grouping of patches into a set provides a number of conveniences, such as a predetermined sequence in which each constituent patch can be applied.

Description

A brief description of the patch or patch set associated with the patch ID.

Product

The name of the product to which the patch applies, such as WebLogic Server, Workshop for WebLogic, WebLogic Portal, JRockit, or Oracle Service Bus.

CR

A number assigned to a problem report that is used internally by My Oracle Support.

Category

The product category to which the patch applies. For example:

- JMS—A patch for WebLogic Java Message Service

- Security—A patch for the WebLogic Security Service

- Console—A patch for the WebLogic Administration Console

Select

To download a patch, select the check box for that patch.

Viewing Patch and Patch Set Details

The following sections describe the details that can be viewed for patches and patch sets:

- Viewing Details about Patches

- Viewing Details About Patch Sets

Viewing Details about Patches

For detailed information about a patch, click the icon beside the appropriate patch identifier.

Smart Update displays a dialog box with the details defined in Table 3-4.

Table 3-4 Key to Patch Details

This detail

Specifies

Version

The version of the product for which the patch is intended.

Severity

Whether the patch is critical or optional.

Size (KB)

Identifies the size, in kilobytes, of the patch.

Restart

The software component that must be restarted after the patch is applied.

Status

Availability of the patch:

- Public—Indicates the patch is publicly available

- Private—Indicates the patch is customized for one or more customers and is not generally available

OS

The operating system on which the patch is designed to run

Invalidated

A patch that is now invalidated for one of the following reasons:

- A replacement for the patch is now available. The identifier of the replacement patch is provided.

- The patch is deprecated, and no replacement patch is available.

Note: Invalidated patches detected in the patch download directory are automatically reported by Smart Update.

Replaces

A patch intended to replace an existing, invalidated patch. The identifier of the invalidated patch is displayed.

Click OK to dismiss the Patch Details dialog box and return to the main Smart Update window.

Viewing Details About Patch Sets

For detailed information about a patch set, click the icon beside the appropriate patch set identifier.

Smart Update displays a dialog box with the details defined in both Table 3-3 and Table 3-5.

Table 3-5 Key to Patch Set Details

This detail

Specifies

Patches Included in Set

The identifier of each patch included in the set. When you click a patch identifier, the dialog box is expanded with details about the corresponding patch.

Size (KB)

Combined size, in kilobytes, of all the patches in the set.

Invalidated

A patch set that is now invalidated for one of the following reasons:

- A replacement for the patch set is now available. The identifier of the replacement is provided.

- The patch set is deprecated, and no replacement is available.

Note: Invalidated patch sets detected in the patch download directory are automatically reported by Smart Update.

Viewing Currently Downloaded Patches

The Downloaded Patches panel of the Get Patches tab displays a list of the patches residing in the patch download directory for the currently selected target installation. All downloaded patches are listed, regardless of whether they have been applied.

The Downloaded Patches panel may be viewed in both the Get Patches tab and Manage Patches tab. When this panel is viewed in theGet Patches tab, a Delete button is displayed next to each patch to allow you to delete the patch; when viewed in the Manage Patches tab, an Apply button is available to allow you to apply the patch to your current installation. For more information, see Applying and Managing Patches.

If you designate a nondefault directory as the patch download directory, the list of patches and patch sets shown in the Downloaded Patches panel is updated accordingly. If patches have been downloaded to multiple locations in your system environment, and those locations are accessible through networked disk drives, you can access those patches simply by designating a new patch download directory. For more information about designating a different patch download directory, see Downloading Publicly Available Patches.

For patch sets listed in the Downloaded Patches panel, you can choose whether to display or hide the entries for individual patches in each patch set. You can make your choice in the Preference dialog box, available from the File menu, as described in Displaying Patch Sets in the Downloaded Patches Panel. The ability to hide listings for individual patches in a patch set is supported only for the Downloaded Patches panel.

Applying and Managing Patches

After you download patches into the patch download directory, you can apply them to a target installation. The following sections explain how to apply and manage patches:

- About the Manage Patches Tab

- About Patch Profiles

- Applying a Patch to the Target Installation

- Removing a Patch or Patch Set from the Target Installation

About the Manage Patches Tab

When you are ready to apply patches to the target installation, select the Manage Patches tab in the Smart Update main window.

The Manage Patches tab contains the following panels:

- A patch profile panel—Displays a list of the patches that have been applied. The Default patch profile, which lists the patches that have been applied to the entire target installation, is described in About Patch Profiles. This panel also contains one additional tab for each custom profile you created.
Note that when you apply a patch set, the list of patches in the profile includes entries for both the patch set itself and each patch in the set.

- Downloaded Patches—Displays a list of the patches that currently reside in the patch download directory but have not yet been applied to the target installation through the currently selected patch profile. After you apply a patch to the target installation, the entry for that patch is removed from the list in the downloaded patch panel of the Manage Patches tab for the appropriate patch profile. For more information, see Applying a Patch to the Target Installation.

About Patch Profiles

Smart Update uses the notion of a patch profile to help manage sets of patches. A patch profile contains a list of patches that have been applied. Every target installation has a default patch profile defined. Patches listed in the default patch profile are in effect installation-wide, and are also in effect, by default, for all applications, WebLogic domains, and WebLogic Server instances that run from that installation.

To meet typical maintenance requirements, the default patch profile is the only profile that most users need to work with. The default patch profile is available out-of-the-box and does not need to be configured.

Many users may choose to create custom patch profiles. Custom patch profiles enable you to associate specific servers, domains, or applications in an installation with a set of one or more patches that are not intended to be in effect installation-wide. However, the use of custom patch profiles raises the level of complexity of maintaining product installations. Custom patch profiles are described in Chapter 6, "Patching Individual Applications, Domains, or Servers."

Applying a Patch to the Target Installation

To apply a patch to the target installation, click Apply next to that patch in the Downloaded Patches panel.

Note:
To avoid unexpected errors, stop the server when applying a patch.

When you apply a patch to the target installation, the following events occur:

1. The patch is validated against patches in the current patch profile.

2. If there are no patch conflicts, the patch is applied.
If there are conflicts, the Patch Installation Validation dialog box is displayed, summarizing conflicts. The patch is not applied.

3. If the patch is applied, the patch is added to the current patch profile. The patch is no longer listed in the Downloaded Patches panel of the Manage Patches tab for this profile.
Note that this patch continues to be listed in the Downloaded Patches panel that appears in the Get Patches tab.

If conflicts are detected during validation, you must resolve those conflicts before you can apply the patch. For more information, see Resolving Patch Conflicts.

Note:
If you have multiple patch profiles for the target installation, and you apply a patch that affects installation-wide resources, Smart Update displays a warning popup to alert you. Examples of patches that are in effect for an entire installation include those that replace system resources, or that address a security advisory. If you choose to proceed, Smart Update automatically applies the patch to all patch profiles defined in the target installation.
For certain patch types, the applied maintenance may not get activated automatically in the user applications and WebLogic domains. Depending on the patch type, regardless of whether it was applied to the default profile or a custom profile, and the system environment and configuration, administrators may need to do one or more of the following:

- Start or restart a server

- Start or restart an application

- Undeploy/deploy an application

- Edit a WebLogic domain or server start script

- Deploy a library module to an application

- Edit a domain configuration file

- Edit an application descriptors file

Removing a Patch or Patch Set from the Target Installation

If you have applied a patch or patch set that you need to remove from the target installation—for example, the patch does not correct the problem as expected, the patch is not needed, or the patch creates new problems and you are awaiting a replacement patch from My Oracle Support—click Remove next to the listing of that patch in the corresponding patch profile.

Note:
To avoid unexpected errors, stop the server when removing a patch.

When you remove a patch from the target installation, the following events occur:

1. The removal operation is validated, similar to the validation that occurs when you apply a patch. When you remove a patch from the target installation, Smart Update checks the current patch profile to determine if any other patches depend on the one you are removing.

2. If a conflict is detected, Smart Update displays the Patch Removal Validation dialog box and identifies the specific conflict. If you have a conflict, you must resolve it before you can remove the patch.

3. If no removal conflict is detected:

1. The patch is removed from the target installation and from the current patch profile.

2. The patch is added to the list displayed in the Downloaded Patches panel, in the Manage Patches tab, under the current patch profile list.

When removing patches, note the following:

- If you have multiple patch profiles for the target installation and you remove a patch that affects installation-wide resources, Smart Update displays a warning popup to alert you. If you choose to proceed, Smart Update automatically removes the patch from all patch profiles defined in the target installation.

- If you remove a patch that is not installation-wide, that patch is removed from the current patch profile.

- If you remove a patch set, or a patch that is a member of a patch set, Smart Update displays a message dialog box advising you that the operation affects a patch set and prompts you to confirm the removal operation.

- If you remove a patch set, the entries for the patch set and each member patch are removed from the patch profile and the target installation.

- If you remove a patch that is a member of the patch set, but retain the other member patches, the entries for both that patch and the corresponding patch set are removed from the current patch profile. (The entries for remaining member patches of the patch set are retained.)

- After removing a patch that affects the run-time behavior of server instances in the product installation, restart the servers for the patch removal to take effect.

For information about correcting removal conflicts, see Resolving Patch Conflicts.

Resolving Patch Conflicts

Smart Update protects your system by validating the compatibility of any patch that you want to download, apply, or remove with the other patches that have been applied to the target installation. Any validation problem that occurs is reported as a patch conflict, which you can resolve before completing the patch operation.

This section describes the types of conflicts that may be identified during the following validation processes:

- Validation When Downloading Patches

- Validation When Applying Patches

- Validation When Removing Patches

Each section also provides instructions for resolving each type of conflict.

Validation When Downloading Patches

The report of a conflict when downloading a patch does not prevent you from completing the download process. It is good practice, however, to resolve any conflicts reported at this stage, before proceeding with the download.

Table 3-6 describes the types of conflicts that may be reported when a patch is being validated for download, and it provides procedures for correcting each type.

Table 3-6 Conflict Conditions When Downloading a Patch

If this conflict is reported

The patch you have selected for download

To resolve this conflict and download the selected patch

Prerequisite not met

Cannot be applied until one or more other patches are applied

1. Note the identifiers of the prerequisite patches.

2. Click Cancel to terminate the download process for the selected patch.

3. Download and apply the prerequisite patches, using the identifiers noted in step 1.

4. Download the selected patch.

Out of sequence

Requires that you first remove one or more other patches that have been applied

1. Note the identifiers of the patches that must be removed.

2. Click Cancel to terminate the download process for the selected patch.

3. Remove the patches that are identified.

4. Download and apply the patch.

5. Re-apply the patches removed in step 1.

Mutually exclusive

Cannot coexist with one or more patches that have been applied

1. Note the identifiers of the patches that have been applied.

2. Identify the patch or patches for which you have the greater need (either the patch selected for download or the patches that have been applied).

If you determine that you need the patch selected for download, remove any patches identified in the conflict, then download and apply the selected patch.

If you determine, instead, that you need the patches that have been applied, simply exit from Smart Update.

Caution:
Smart Update lets you download patches in any sequence you like. However, if any patches must be applied in a specific sequence, Smart Update enforces that sequence at the time you apply them. If you attempt to apply a patch that is out of sequence with another, Smart Update reports a patch conflict, which you must resolve before applying the patch.

Validation When Applying Patches

During the process of applying a patch, various conflicts may be reported. Once a conflict has been reported, it must be resolved before you can apply the patch.

Table 3-7 describes the types of conflicts that may be reported when a patch is being validated when you attempt to apply it, and it provides procedures for correcting each type.

Table 3-7 Conflict Conditions When Applying a Patch

If this conflict is reported

The patch you have selected to apply

To resolve this conflict and apply the selected patch

Prerequisite not met

Cannot be applied until you apply one or more other patches

1. Note the identifiers of the prerequisite patches.

2. Click Cancel to terminate process of applying the selected patch.

3. Download and apply the prerequisite patches identified in step 1.

4. Apply the patch you originally selected.

Out of sequence

Cannot be applied until you remove one or more patches that you applied earlier

1. Note the identifiers of the patches that must be removed.

2. Click Cancel to terminate the process of applying the selected patch.

3. Remove the patches identified in step 1.

4. Apply the patch you originally selected.

5. Re-apply the patches removed in step 3.

Mutually exclusive

Cannot coexist with one or more patches that you applied earlier.

Choose the patch you want applied to the target installation and, if necessary, apply it.

Validation When Removing Patches

Table 3-8 describes the conflict that may be identified when you attempt to remove a patch, and a procedure for resolving that conflict.

Table 3-8 Conflict Condition When Removing a Patch

If this conflict is reported

The patch you have selected for removal

To resolve this conflict and remove the selected patch

dependency violated

Is required by one or more patches that have been applied

1. Note the identifiers of the dependent patches.

2. Click Cancel to terminate the download procedure.

3. As appropriate, remove the dependent patches.

4. Remove the patch that you originally selected for removal.

Creating and Using Maintenance Snapshots

To make it easy for you to provide the information needed by My Oracle Support to help you resolve problems, Smart Update provides a simple method of capturing information about the patches that have been applied to a specific patch profile. This method is to create a maintenance snapshot, a plain ASCII file that contains information about the patch profile selected in the Manage Patches tab, including the identity of each patch that has been applied to that profile.

If you report a problem, My Oracle Support requests this snapshot as the first step in providing you with a solution. Therefore, if you experience a problem, it is strongly recommended that you prepare a maintenance snapshot before contacting Customer Support.

It takes only a moment to create a maintenance snapshot, using the Smart Update graphical interface:

1. In the Target Installation panel in the main Smart Update window, select the product installation for a problem that is being reported.

2. From the Manage Patches tab, select the patch profile with which you are reporting a problem.

3. Choose Patches > Patch Profiles > Save Snapshot
A dialog box prompts you to specify the name and location of the maintenance snapshot. By default, the maintenance snapshot file is created in MW_HOME\utils\bsu. If you specify a different location, ensure that you have the privileges required to access a file there.

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

You can also use the Smart Update command-line interface to create a maintenance snapshot. For an example, see Command-Line Interface Examples.

It is recommended that you observe the following practices whenever you create a maintenance snapshot:

- Save all maintenance snapshots for a particular product installation in a place where you can find them easily.

- Use a file name for the maintenance snapshot that helps you distinguish among other snapshots. For example, indicate the patch profile name, such as MyCustomProfile.txt.

Whenever you send a maintenance snapshot to My Oracle Support, keep a log of your support-related activities.

Applying a Patch to the Client

WebLogic Server patches can be applied to the server, client, or both. This section describes what you must do to apply the patch to the client.

To apply the patch to the client in addition to the server:

1. Download and apply the patch using Smart Update.

2. Look for the patch JAR file in MW_HOME\patch_wls1030\patch_jars.

Note:
This is different from the download directory (MW_HOME\utils\bsu\cache_dir).Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

3. Copy the class files that are in the patch JAR file to the appropriate directory, or reference the class JAR in the JMS client environment by placing the path of the directory in which it is located at the beginning of the classpath.

To apply the patch to the client only:

1. Download the patch by using Smart Update.
The patch is copied to MW_HOME\utils\bsu\cache_dir by default. If you specified a different directory (see Specifying Other Middleware Home Directories), the patch is copied to that directory.

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

2. Extract the patch JAR file from the patch file (for example, extract CR322355_100mp1.jar file from the patch file 7XHQ.jar).

3. Copy the class files that are in the patch JAR file to the appropriate directory, or reference the class jar in the JMS client environment by placing the path of the directory in which it is located at the beginning of the classpath.

4 Downloading and Installing Maintenance Packs

This section includes the following topics:

- Overview

- Viewing Available Maintenance Packs

- Applying the Selected Maintenance Pack

- Upgrading Web Server Plug-Ins

Overview

You can install maintenance packs (patch sets) using Smart Update, which enables you to retrieve code and media archives from My Oracle Support. Media archives can be retrieved only for components currently installed in the target Middleware home directory.

Note:
If you also need to install patch sets for other Fusion Middleware 11g Release 1 products, such as SOA or WebCenter, that are installed in your WebLogic Server environment, refer to the Oracle Fusion Middleware Patching Guide before installing WebLogic Server patch sets or updating your WebLogic Server installation.

For offline systems, you must acquire an upgrade installer. See "Downloading an Upgrade Installer From My Oracle Support" in Oracle WebLogic Server Installation Guide.

When installing a maintenance pack, Smart Update creates a backup file containing the state of the current installation and information about files that were added during the upgrade. This backup file is used to restore the system state if any errors occur during installation, and when you uninstall or roll back a maintenance pack installation.

For a typical upgrade installation of WebLogic Products and Oracle Service Bus, a minimum of 430 MB of available disk space is required.

When installing a maintenance pack, note the following important information:

- Using the Node Manager in a Clustered Environment

- Removing Pointers to Custom Patch Profiles

Using the Node Manager in a Clustered Environment

If you are using Node Manager to manage your servers in a clustered environment, you should back up the following directory and files on all systems that are running the Node Manager before upgrading your installations:

Windows:

WL_HOME\common\nodemanager
WL_HOME\server\bin\startNodeManager.cmd

UNIX:

WL_HOME/common/nodemanager

WL_HOME/server/bin/startNodeManager.sh

In these path names, WL_HOME is the root directory of the product installation, for example, c:\Oracle\Middleware\wlserver_10.3.

After the upgrade installation is complete, you should restore these files.

For more information about Node Manager, see Node Manager Administrator's Guide for Oracle WebLogic Server.

Removing Pointers to Custom Patch Profiles

All patch profiles are specific to a maintenance pack level of a product installation. When you upgrade the maintenance pack level of a product installation in which you have been using custom patch profiles, you must modify the appropriate WebLogic domain or server start scripts so that they no longer point to those custom profiles.

Viewing Available Maintenance Packs

You can display the Maintenance Pack Update window periodically to check for available maintenance pack updates. When you log in to Smart Update, it checks the version numbers of the products associated with the current target installation, and then connects to My Oracle Support to check for available maintenance packs. The Maintenance Pack Update window includes three panes:

- Installed Products—The left pane of the Maintenance Pack Update window which contains a tree displaying product and release information for products installed in the target installation directory.

- Upgrade Options—The top-right pane, which lists the maintenance packs, if any, that are available for the installed products.

- Downgrade Options—The bottom-right pane, which lists the versions of the product to which you can revert your installation, if applicable. For details about uninstalling maintenance pack upgrades using Smart Update, see Chapter 7, "Uninstalling Maintenance Packs and Patches."

Note:
Smart Update checks for only those products that are associated with the current target installation. If you have multiple Middleware home directories on your system, you must run Smart Update once for each directory to ensure that available maintenance packs are installed for each one. For more information about Middleware home directories, see Choosing a Target Installation.

Applying the Selected Maintenance Pack

To install maintenance packs using the Maintenance Pack Update window, perform the following steps:

Note:
Verify if the install directory entry for Workshop for WebLogic in registry.xml points to the correct location before upgrading. If not, correct it by manually editing registry.xml.

1. Make backup copies of any files or applications that you have created in the product home directory; for example, in WL_HOME. (As part of the upgrade procedure, the installation program automatically overwrites any files, including applications, that you have created in this directory. Files that are outside of the product home directory—for example, in user_projects—are not affected.)

2. Shut down any servers that are running. Hot installation of a maintenance pack is not supported.

3. Start Smart Update, as described in Chapter 2, "Starting Smart Update."

4. In the Smart Update main window, choose Maintenance Packs > Update. This displays the Maintenance Pack Update window.

5. In the Installed Products pane of the Maintenance Pack Update window, select the release for the product you want to update.
If any maintenance packs are available, they are displayed in the Upgrade Options section of the window.

6. In the Upgrade Options pane, select the maintenance pack to be installed and click OK to begin the download.

7. The Oracle Installer Welcome window is displayed, from which you can proceed with the installation. You can cancel the installation at any time by clicking Exit.
After the installation is complete, the Maintenance Pack Update window is displayed, indicating the upgraded release level in the Installed Products pane. Choose Exit to close the Maintenance Pack Update window. The Smart Update main window reappears after quitting the Maintenance Pack Update window.

Upgrading Web Server Plug-Ins

If you are using a Web server with the product installation, it is important that you keep your Web server up to date to ensure you have all the latest security patches and support. Updated Web server plug-ins are included when you upgrade your WebLogic Server installation. Although it is not required, you may want to replace the Web server plug-ins installed with your Web server with the updated versions.

For details about installing the Web server plug-ins, see Using Web Server Plug-Ins with Oracle WebLogic Server.

5 Activating Applied Patches in Your Installations and Applications

This section includes the following topics:

- Overview

- Classpath, Extended Classpath, and Native Library Patches

- Modifying a Start Script

- Using the Start Script Editor

- Pointing All Domains and Servers at Patches Through Custom Scripts

- Module Patching

- Native Binaries and Other Artifacts Patches

- Shared Archive Patches

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 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 are to be modified:

- Patches That Must Be Referenced By Start Scripts

- Patches That Replace Resources For All Applications, Domains, and Servers

- Patches That Must Be Deployed and Referenced By Applications

- How Patch Files Are Stored on Your System By Smart Update

- Structure of the Installation-Level Patch Directories

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 Must Be Referenced By Start Scripts

- Patches That Replace Resources For All Applications, Domains, and Servers

- Patches That Must Be Deployed and Referenced By Applications

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 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 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 (a) modify the appropriate WebLogic domain or server start scripts, if necessary, so they point to the patch and (b) restart the corresponding domains or servers.

Patches That Replace Resources For All Applications, 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 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, it is recommended that you create a backup of any system resource that you plan to replace before applying the patch that replaces it.

Patches That Must Be Deployed and Referenced By Applications

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.

How Patch Files Are Stored on Your System By Smart Update

When you download a patch or patch set from My Oracle 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 start 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 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.

Structure of the Installation-Level Patch Directories

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.

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.

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

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, patch_wlp1020, patch_wls1001, and patch_wlw1020 as shown in Figure 5-1), contain the class JAR files from patches that have been applied to the product installation on the system.

A patch JAR file under each product patch directory may contain one or more of the following:

- Classes intended as replacements for classes with the same names in the installation. These classes must be inserted into the WebLogic system classpath.

- Classes required by a product. These classes must 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 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:

- 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 My Oracle 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 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\default\modules

Holds module files that are used by Open Services Gateway initiative (OSGi)-based products. The contents of this directory are not used with WebLogic Server-based products, which load modules through the classpath. For details, see Module Patch Files.

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:

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

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

- profiles\custom-profile-name\modules
Holds module files that are used by OSGi-based products.

- profiles\custom-profile-name\archives
Holds shared archive files that are to be deployed and referenced by the applications that point to this custom patch profile.

patch_product\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

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

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, is applied to the default patch profile, Smart Update performs the following tasks:

- Adds CR99004.jar to the MW_HOME\patch_wls1030\patch_jars directory.

- Creates the following file, if it does not exist already:

MW_HOME\patch_wls1001\profiles\default\sys_manifest_classpath\weblogic_patch.jar

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

Class-Path: C:\Oracle\Middleware\patch_wls1001\patch_jars\CR99004.jar

- Updates the patch registry information in the MW_HOME\patch_wls1001\registry directory.

Native Library Files

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

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_wls1001\profiles\default\native

- Puts libmuxer.so in the following directory:

MW_HOME\patch_wls1001\profiles\default\native

- Updates the patch registry information maintained in the following directory:

MW_HOME\patch_wls1001\registry

Module Patch Files

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

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:

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

MW_HOME\patch_wlevs20200\profiles\default\modules

2. Adds the updated com.bea.wlevs.processor.monitor_2.0.0.0.jar in the MW_HOME\patch_wlevs20200\profiles\default\modules directory

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

Classpath, Extended Classpath, and Native Library Patches

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 or patch set 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, how to modify start scripts using the Smart Update Start Script Editor, and 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 the Workshop IDE. For more information, see the Workshop for WebLogic documentation.

About Pointing Start Scripts at Patches

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

- 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 WebLogic Domains and Servers

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)

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=
%WLS_PATCH_CLASSPATH%;%WLW_PATCH_CLASSPATH%

Note: Most patches provided by My Oracle 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_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 native folder in the installation-level directory for the default patch profile—This folder 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_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 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_wls1030\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 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

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

Sequence in Which Start Scripts Are Executed

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 bin directory of your WebLogic 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 WebLogic 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 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 WebLogic 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.

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, if you are already located in the bin directory:

. ./commEnv.sh

Placeholders for Defining Patch Path Variables in Default Scripts

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

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 product software installed.

Modifying a Start Script

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:

1. Create a custom patch profile, to which the patches are applied for the domain, or server that runs on a product installation.

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

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

Creating a Custom Patch Profile

Using the Start Script Editor

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.

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.

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

Script Snippet for Windows

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

Script Snippet for UNIX

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:

1. In Smart Update, select a target installation from the Target Installation panel.

2. Choose Patches > Start Script Editor.

3. In the Start Script Editor dialog box:

1. 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 Maintenance Updates."

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

3. Open the start script you want to modify.
For detailed instructions, see Opening a Start Script.

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

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

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

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

- Modifying the Domain Start Script

- Modifying the Start Script for All Managed Servers or a 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 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.

Table 5-6 Modifying Scripts

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 a 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 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 the following table.

Table 5-7 Modifying Script

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

Table 5-8 Modifying Start Script

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 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. This approach is recommended 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.

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 ensure 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_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).

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

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 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.Note that starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

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

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.

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

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

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

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

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

Module Patching

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.

Module Patching in WebLogic Server

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.

Module Patching in OSGi-Based Products

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 Patches

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.

Shared Archive Patches

In this section, we describe how shared archive patches are deployed and referenced by applications.

Overview

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.

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.

Archive Replacement Compared with Insertion

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.

Patch Removal

When you remove a patch, you must un-deploy the patch explicitly in addition to patch removal through the tool.

For More Information

To learn more about deploying and un-deploying shared libraries, see Deploying Applications to Oracle WebLogic Server. To learn more about shared libraries, see Developing Applications for Oracle WebLogic Server.

Default Application of Shared Archive Patches

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.

Activating Shared Archive Patches in Custom Profiles with Application Scope

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:

1. Deploy the patch in the custom profile.

2. 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_weblogic[version]/profile/custom-profile-name/archives

For example: MW_HOME/patch_wls1001/profile/customProfile

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

Updating Application Descriptors

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>

6 Patching Individual Applications, Domains, or Servers

Smart Update enables you to point a domain or server at a set of patches that are not necessarily intended for the entire installation by using a custom patch profile.

This section includes the following topics:

- About Patching Domains or Servers

- About Patching Applications, Domains, or Servers

- Creating a Custom Patch Profile

- Pointing Domains and Servers at a Custom Patch Profile

- Managing Custom Patch Profiles in a Node Manager Environment

About Patching Domains or Servers

By default, when you download and apply patches, those patches are in effect for the entire target installation. Every domain and server that is configured to run from such an installation runs against the patches applied to it. Sometimes, however, individual servers or domains within a production environment need to run at different patch levels. To accommodate this need, Smart Update enables you to point individual domains, servers, or clusters at specific patches that are not necessarily in effect installation-wide.

For example, if you have (a) multiple products installed in a Middleware home directory, and (b) domains that exclusively use only one of those products, it is recommended that you point those domains at only those patches that have been applied to the specific product used by the domain.

At a high level, the work required to point an individual domain or server at one or more patches that are not intended to be in effect installation-wide can be summarized as a three-step procedure:

1. Create a custom patch profile.

2. In the appropriate start script for the corresponding domain or server, insert a pointer to the custom patch profile.

3. Apply the desired patches to the custom patch profile.

Figure 6-1 provides a detailed version of this procedure.

Figure 6-1 How to Point an Individual Domain, Cluster, or Server at a Custom Patch Profile

About Patching Applications, Domains, or Servers

Smart Update enables you to apply Shared Archive patches to specific applications. When you apply a shared archive patch to a default patch profile, it is installed automatically. However, when you apply an application-scoped patch to a custom patch profile, it should be explicitly deployed: see Shared Archive Patches.

How Custom Profiles Can Patch Individual Domains, Servers, and Applications

By default, all patches included in the default patch profile are in effect for all domains and servers in an entire installation. The patches in a custom patch profile, however, can be put into effect for any subset of domains or servers within an installation. As noted in Patches That Replace Resources For All Applications, Domains, and Servers, patches that replace system-wide resources cannot be selectively targeted by a subset of domains or servers. Such selective targeting is possible, however, for patches with classes or library files that are loaded through a start script and thereby supersede existing, same-named resources in the system.

The following sections provide background information about how custom patch profiles can be used to patch individual domains and servers:

- How a Domain or Server Can Point to a Patch in a Custom Profile

- Best Practices for Using Custom Patch Profiles

How a Domain or Server Can Point to a Patch in a Custom Profile

When you create a domain using the Configuration Wizard, the Configuration Wizard creates the following scripts for the domain:

- setDomainEnv—Script used to set domain-level environment variables, including those used by all servers.

- startWebLogic—Start script used by any WebLogic Server instances in the domain that are not Managed Servers.

- startManagedWebLogic—Start script used by Managed Servers in the domain, including those in a cluster.

Note:
For details, see Default Script that Defines Class and Library Paths for All WebLogic Domains and Servers.

By default, the values of the PATCH_CLASSPATH, WEBLOGIC_EXTENSION_DIRS, PATCH_LIBPATH, and PATCH_PATH variables provided in the product installation script, commEnv, are used by all the server instances that run on that installation. If, however, you override these values for any of the variables in a domain-level script, the new values are used only by the WebLogic Server instances that are started by those scripts.

Note:
The definition of a given patch variable should reference no more than one patch manifest JAR. If multiple patch manifest JAR files are referenced, unpredictable behavior may occur at run time.

Modifying the definition of a patch path variable in a start script is a convenient way of pointing servers started by that script at the patches included in a custom patch profile. For example, if you want to point a server at the WebLogic system classes in a patch that has been applied to a custom patch profile, you simply add a definition of the PATCH_CLASSPATH variable to that server start script, setting the variable to the path of the patch manifest JAR file in the custom patch profile. Similarly, you can point a server or domain at a native library file in a custom patch profile by adding a reference to the directory in the custom patch profile that contains that native file. To add this reference, you add a definition of the PATCH_PATH or PATCH_LIBPATH variable to the start script for the appropriate server or domain.

Note:
When adding a definition of a patch path variable to a start script, 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. But if you use the start scripts that are created, by default, with standard tools such as the Configuration Wizard, and maintain them in the default locations determined by those tools, Smart Update can provide a structured and predictable method of locating the start scripts that need to be modified and suggesting the specific changes that must be made to those scripts.

Figure 6-2 shows two patch profiles used in an installation: the default patch profile and a custom patch profile. In this figure:

- The default patch profile includes patches 1, 2, and 3. By default, all domains and servers running in the sample installation are pointing at it.

- The custom patch profile includes patch 4. One server in the sample domain is pointing at it.

Figure 6-2 How to Point an Individual Domain, Cluster, or Server at a Custom Patch Profile

Example Use of PATCH_CLASSPATH to Point a Server at Patch Classes

The following PATCH_CLASSPATH variable references the patch manifest JAR file weblogic_patch.jar, located in the custom profile ProductionServer1:

set PATCH_CLASSPATH=
%BEA_HOME%\patch_wls1001\profiles\ProductionServer1
\sys_manifest_classpath\weblogic_patch.jar

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

When the preceding definition is added to the startWebLogic script for a given domain, server instances that are started in that domain by that script load the class files into the WebLogic server classpaths that are referenced by the weblogic_patch.jar file in the ProductionServer1 custom profile. This classpath loading occurs when the following line in the commEnv script is subsequently executed (PATCH_CLASSPATH is shown in bold):

set WEBLOGIC_CLASSPATH=%PATCH_CLASSPATH%;%JAVA_HOME%\lib\tools.jar;
%WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\weblogic.jar;
%WL_HOMEE%\server\lib\webservices.jar

Note:
The weblogic_patch.jar in the ProductionServer1 profile may reference a set of patch JAR files that is entirely different from the set of patch JAR files referenced in the weblogic_patch.jar of the default patch profile.

If you want a server in a domain, or any domain in an installation, to continue to point to patches in the default patch profile, you do not need to change the start script for that server or domain if you use the default scripts for servers and domains provided by the Configuration Wizard. If, however, you want one or more servers or a domain to point at a custom patch profile, ensure that the start script you modify affects only the targeted servers or the domains.

For information about the sequence in which start scripts are executed, and how particular definitions of patch path variables affect servers started by scripts with patch path variable definitions, see Sequence in Which Start Scripts Are Executed.

Pointing to Custom Patch Profiles in OSGi-based Products

In a text editor, open the start script for the server (for example, in a WebLogic Event Server domain, startwlevs.cmd on Windows, startwlevs.sh on UNIX) and add the -DBEAPatchProfile property to this script as follows:

if "%1" == "-dgc" goto rundgc

"%JAVA_HOME%\bin\java" -Dwlevs.home="%USER_INSTALL_DIR%" -Dbea.home="%BEA_HOME%"
-Dcom.bea.core.security.username=wlevs -Dcom.bea.core.security.password=wlevs
–DBEAPatchProfile=custProfile
-jar "%USER_INSTALL_DIR%\bin\wlevs_2.0.jar" %1 %2 %3 %4 %5 %6

goto finish
:rundgc

"%JAVA_HOME%\bin\java" %DGC_ARGS% -Dwlevs.home="%USER_INSTALL_DIR%"
-Dbea.home="%BEA_HOME%" -Dcom.bea.core.security.username=wlevs
-Dcom.bea.core.security.password=wlevs –DBEAPatchProfile=custProfile
-jar "%USER_INSTALL_DIR%\bin\wlevs_2.0.jar" %2 %3 %4 %5 %6
:finish

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

When the modified start script is executed, only those patches applied to the patch profile specified in the script are referenced by the OSGi launcher.

Best Practices for Using Custom Patch Profiles

This section provides important information about the use of custom patch profiles:

- Avoiding Proliferation of Custom Profiles

- Modifying Domain and Server Start Scripts

- Removing Patches That Affect Installation-Wide Resources

Avoiding Proliferation of Custom Profiles

When you want to point a domain or server at a new set of patches you have downloaded, try to apply the patches to an existing patch profile, if possible. To change the set of patches at which a specific domain or server points, change the content of the custom patch profile that contains the patches. This approach is always preferable to creating a new custom patch profile and modifying start scripts so they point to it. Avoid creating a new profile for each patch that you download. By keeping the number of profiles you create to a minimum, you can more efficiently take advantage of the patch validation and dependency checking capabilities built into Smart Update and the My Oracle Support Repository.

In addition, when you minimize the number of custom profiles you use, you minimize the number of start script modifications that you must maintain. As a result, the likelihood of introducing errors in your scripts is reduced. In addition, the work required to remove patches is simplified: you simply update the appropriate patch profile; the need to update scripts is minimized.

Modifying Domain and Server Start Scripts

A great deal of flexibility is provided in the use of start scripts. The use of specific names and locations for start scripts is not enforced. However, by staying within the default directory structure that the Configuration Wizard creates for a domain, and by retaining the location and structure of the start scripts that are provided, you maximize your ability to rely on Smart Update to locate and generate suggested changes for start scripts that are required when custom profiles are used.

In general, when pointing a domain or server at a custom patch profile, keep in mind the following guidelines:

- Before modifying a start script, make a backup copy.

- Modify the start script at the most general level possible. For example, to point a domain at a custom patch profile, modify the setDomainEnv script, rather than each script that starts a server within the domain. When you implement this practice, you minimize the number of start scripts that you need to modify and maintain.

- Never point a domain or server at more than one patch profile. Patch validation is performed within the boundaries of a single patch profile; it is never performed for multiple profiles simultaneously.

Removing Patches That Affect Installation-Wide Resources

Generally, there are no restrictions on the set of patches that can be added to a custom patch profile or removed from it. Patches that affect installation-wide resources, however, are automatically placed in all existing patch profiles for a target installation.

If you remove a patch that affects installation-wide resources from any single patch profile (regardless of whether that profile is the default profile or a custom profile), the patch is automatically removed from all patch profiles. If you have multiple profiles in a target installation, and you try to replace or remove a patch that affects installation-wide resources, Smart Update displays a warning.

Creating a Custom Patch Profile

To create a custom patch profile, complete the following steps:

1. In the Target Installation panel, select a product installation.

2. Choose Patches > Patch Profiles > New.

3. In the New Patch Profile dialog box, choose the following:

1. A name for the custom patch profile

2. The initial contents of the profile

Note:
When you create a custom patch profile, Smart Update creates a directory for it, using the name you have chosen for the profile. Therefore, to ensure that custom patch profiles can be used with any combination of hardware and operating system supported by products software, only alphanumeric characters may be used in custom patch profile names.

4. Click Create.

The following topics provide more information about custom profiles:

- Initial Contents of a Custom Patch Profile

- Cloning a Patch Profile

- Adding Patches to a Custom Patch Profile

- Deleting a Custom Patch Profile

Related Topics

- About Patching Domains or Servers

- How Custom Profiles Can Patch Individual Domains, Servers, and Applications

- How a Domain or Server Can Point to a Patch in a Custom Profile

- Best Practices for Using Custom Patch Profiles

Initial Contents of a Custom Patch Profile

Custom patch profiles may contain the following types of patches:

- Classes that can be loaded in the WebLogic system classpath

- Classes that can be loaded in the extended classpath, for applications deployed on WebLogic Server

- Native library files that can be added to the library path

By default, any installation-wide patches that have been applied to the target installation are automatically included whenever you create a new patch profile. Smart Update gives you the option, however, of creating a patch profile that initially contains no patches.

When you clone the contents of an existing patch profile to create a custom patch profile, only a subset of the patches from the existing patch profile are physically duplicated on disk:

- Patch JAR files are not duplicated. A single patch JAR file is shared by all the patch profiles on your system that reference them.
Replacement patches are not duplicated. When a patch replaces a system resource at the time it is first applied, the system resource is not replaced each time the patch is automatically duplicated in a custom patch profile, nor is a duplicate copy made of the patch container that is referenced by a duplicate entry for the patch in the custom patch profile.

- Native library files from patches that are loaded into the system path at server start time are duplicated in the installation-level patch directory. If disk space is a concern, verify that the amount of space occupied by native library files that are duplicated by a custom patch profile is not causing a problem.

Note:
Patches that contain replacements for files or other artifacts are automatically applied to the entire installation.

Cloning a Patch Profile

If you want to create a custom patch profile that includes the same patches in an existing patch profile, you can clone the existing profile and then customize it as needed, by adding or removing patches. This technique is convenient for creating custom patch profiles quickly.

Note:
Patches that affect installation-wide resources are included in all patch profiles created in a target installation. You cannot remove this type of patch from one profile without removing it from all patch profiles on the target installation. If you attempt to do so, Smart Update displays a warning message.

Adding Patches to a Custom Patch Profile

After you create a custom patch profile, you can add or remove patches to it, just as you added or removed patches from the default patch profile:

1. From the Manage Patches tab, select the custom patch profile you have created.

2. To add a patch to the profile, select the patch you want to add from the Downloaded Patches panel, and click Apply.

3. To remove a patch from the profile, select that patch from the list displayed for the patch profile, and click Remove.

When you apply a patch to the target installation, the following events occur:

1. The patch is validated against patches in the current patch profile.

2. If there are no patch conflicts, the patch is applied.

Note:
Though the patch may be validated and applied to the target installation, any patch containing either classes to be loaded into a classpath or native library files to be loaded into a library path does not take effect until you complete the following procedure:

1. Modify the appropriate domain or server start scripts, if necessary, to point to the patch.

2. Restart the appropriate domains, servers, or applications. Shared archive patches should be explicitly referenced by the application, as described in Shared Archive Patches.

If conflicts are detected, the Patch Installation Validation dialog box displays a summary of those conflicts. The patch cannot be applied until the conflicts are resolved. For more information, see Resolving Patch Conflicts.

3. When the patch is applied, it is added to the current patch profile. The patch is no longer listed in the Downloaded Patches panel of the Manage Patches tab for this profile.

Note:
The listing for this patch in the Downloaded Patches panel of the Get Patches tab is retained.

Deleting a Custom Patch Profile

To delete a custom patch profile, complete the following steps:

1. From the Manage Patches tab, select the custom patch profile you want to delete.

2. Choose Patches > Patch Profiles > Delete.
A confirmation dialog box is displayed, giving you the option of continuing or canceling the delete operation.

When deleting a custom patch profile, keep in mind the following:

- Any start script for a domain or server may fail if it points to a custom patch profile that has been deleted. (Instructions for pointing a domain or server at a patch profile are provided in Pointing Domains and Servers at a Custom Patch Profile.)

- When you delete a custom patch profile, the patches associated with it are not removed.

- You cannot delete the default patch profile. If you try to do so, Smart Update displays an error message.

Pointing Domains and Servers at a Custom Patch Profile

To point a domain or server at a custom patch profile you have created, complete the following steps:

1. Make a backup copy of each script you plan to modify.

2. In the Target Installation panel within Smart Update, select a target installation.

3. Choose the Patches > Start Script Editor menu option. The Start Script Editor dialog box is displayed.

4. In the Start Script Editor dialog box:

1. Choose the custom patch profile to which the domain or server will point.

2. Open the start script you want to modify. For instructions, see Opening a Start Script

3. Add the patch path variables that reference your new custom patch profile. Smart Update provides a code snippet containing suggested definitions for the PATCH_CLASSPATH, WEBLOGIC_EXTENSION_DIRS, PATCH_LIBPATH, and PATCH_PATH variables. These definitions reference patches that contain classes and files to be inserted into the system class and library path. However, depending on the content of the custom patch profile, and the specific patch path variables you need to reference, you might need to make different modifications.

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

The default start script for the WebLogic Server product home directory is WL_HOME\common\bin\commEnv. It contains default values for the following variables used for inserting patch files into a classpath or library path:

- PATCH_CLASSPATH

- WEBLOGIC_EXTENSION_DIRS

- PATCH_LIBPATH

- PATCH_PATH

For details, see Default Patch Path Environment Variables.

If you add definitions for these variables to a server or domain start script, your new definitions override the default definitions, in the commEnv script, for the corresponding servers or domain. Therefore, whenever you define these variables in a server or domain script, ensure that your new definitions apply to the appropriate server instances.

Also, note the order in which start scripts are executed: after the definition of one of these variables has been set in a script, it is not overridden by any definition in a script that is executed subsequently. For more information, see Sequence in Which Start Scripts Are Executed.

Important Note if You Use Custom Scripts

If you use custom scripts in your environment that do not invoke the WL_HOME\common\bin\commEnv script, you must change the statements in your scripts that set the class and library paths for your environment so that the environment variables you have defined are properly inserted into statements such as Set WEBLOGIC_CLASSPATH and Set PATH.

For example, to set the WebLogic system classpath so that patch JARs in a custom patch profile supersede same-named classes appearing later in the classpath, add the PATCH_CLASSPATH variable as follows, shown in bold:

set WEBLOGIC_CLASSPATH=%PATCH_CLASSPATH%;%JAVA_HOME%\lib\tools.jar;
%WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\weblogic.jar;
%WL_HOME%\server\lib\webservices.jar

For more information about pointing custom scripts at patch profiles, see Pointing All Domains and Servers at Patches Through Custom Scripts.

Related Topics

- How Custom Profiles Can Patch Individual Domains, Servers, and Applications

- How a Domain or Server Can Point to a Patch in a Custom Profile

- Sequence in Which Start Scripts Are Executed

- Best Practices for Using Custom Patch Profiles

- Modifying Domain and Server Start Scripts

- Using the Start Script Editor

Managing Custom Patch Profiles in a Node Manager Environment

If you use the Node Manager in your domain, and all the patches used in your domain are applied to the default patch profile, the servers started by the Node Manager run against those patches automatically. If, however, you use custom patch profiles in a domain that is configured to use the Node Manager, you must complete the additional procedure provided in this section.

To ensure that all the Managed Servers in a domain cluster point to patches in the custom patch profile at startup time, complete the following steps:

1. Ensure that each Node Manager instance is the Java-based version that runs within a Java Virtual Machine (JVM) process. To ensure that Node Manager is restarted automatically whenever the system is restarted, it is recommended that you run every Node Manager instance as follows:

- On Windows platforms: as a Windows service

- On UNIX platforms: as an operating service

Use of the script-based version of the Node Manager is not supported for the procedures presented in this section.

2. If the custom patch profile that must be referenced by the Managed Servers at start time contains patch JAR files for the WebLogic system classpath, but it does not contain native library files that need to be inserted into the system path, you can set the classpath for the affected Managed Servers through the WebLogic Server Administration Console, as follows:

1. Start the Administration Server.

2. Access the WebLogic Server Administration Console by entering the following URL:

http://hostname:port/console

Here hostname represents the DNS name or IP address of the Administration Server, and port represents the number of the port on which the Administration Server is listening for requests (port 7001 by default).

3. In the Change Center of the Administration Console, click Lock & Edit.

4. In the left pane of the Console, expand Environment and select Servers.

5. In the Servers table, click the name of each Managed Server you want to configure. For each Managed Server, complete steps (f) and (g).

6. Choose the Configuration > Server Start menu option.

7. Add the PATCH_CLASSPATH environment variable to the beginning of the Classpath field.

8. Click Save.

9. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.

3. If the custom patch profile that must be referenced by the Managed Servers at start time contains native library files that need to be inserted into the system path, regardless of whether the custom patch profile also contains patch JAR files, you need to edit the Node Manager nodemanager.properties file on each system that hosts a Managed Server in the cluster. Open each such nodemanager.properties file and make the following changes:

1. Set the StartScriptEnabled property to true, as in the following example:

StartScriptEnabled=true

2. Ensure that the StartScriptName property is set to the WebLogic Server start script used for all server instances in the domain. The default start scripts are operating system-specific:
Windows:

startWebLogic.cmd

UNIX:

startWebLogic.sh

For information about modifying the nodemanager.properties file, see "Node Manager Configuration and Log Files" in Node Manager Administrator's Guide for Oracle WebLogic Server.

3. In a text editor, open the setDomainEnv script for the domain (setDomainEnv.cmd on Windows, setDomainEnv.sh on UNIX) and define one or more of the patch path environment variables described in Table 6-1.

For each file or directory identified in Table 6-1 that is included in the installation-level patch directory (MW_HOME\patch_wls1000), add a definition to the setDomainEnv script for the corresponding patch path variable so that the variable points to that file or directory. In Table 6-1, custom-profile represents the name of the custom patch profile created in the installation-level patch directory.

For example, if your system hosts a JAR file called MW_HOME\patch_wls1000\profiles\custom-profile\sys_manifest_classpath\weblogic_patch.jar, add a definition of the PATCH_CLASSPATH variable to the setDomainEnv script that points to that file.

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

Table 6-1 Patch Variables to Define in setDomainEnv for Node Manager Environments

Define the following variable

If the following is present in the custom profile directory

PATCH_CLASSPATH

File:

MW_HOME\patch_wls1001\profiles\custom-profile\
sys_manifest_classpath\weblogic_patch.jar

Purpose of variable:

The PATCH_CLASSPATH variable points to classes in patch JAR files that are to be inserted into the WebLogic system classpath used by each Managed Server that is started by the Node Manager in your domain.

Example:

PATCH_CLASSPATH= "%BEA_HOME%\patch_wls1001\profiles\
myCustomProfile\sys_manifest_classpath \weblogic_patch.jar"

Note: The majority of patches issued by My Oracle Support are referenced by this patch manifest JAR file.

WEBLOGIC_EXTENSION_DIRS

File:

MW_HOME\patch_wls1001\profiles\custom-profile\
sysext_manifest_classpath\weblogic_ext_patch.jar

Purpose of variable:

The WEBLOGIC_EXTENSION_DIRS variable points to classes in patch JAR files that are to be inserted into the classpath of an application that is deployed on WebLogic Server and required by a product.

Example:

WEBLOGIC_EXTENSION_DIRS="%BEA_HOME%\MW_HOME\
patch_wls1001\profiles\myCustomProfile\
sysext_manifest_classpath\weblogic_patch.jar"

Note: Patch manifest JAR files that reference application-level classes are not supported by WebLogic Server 9.1.

PATCH_LIBPATH

Directory (UNIX only):

MW_HOME/patch_wls1001/profiles/custom-profile/native

Purpose of variable:

The PATCH_LIBPATH variable points to native library files to be inserted into the system path through the LIBPATH environment variable.

Example:

PATCH_LIBPATH="${BEA_HOME}/patch_wls1001/
profiles/myCustomProfile/native"

PATCH_PATH

Directory (Windows only):

MW_HOME\patch_wls1001\profiles\custom-profile\native

Purpose of variable:

The PATCH_PATH variable points to native library files to be inserted into the system path through the PATH environment variable.

Example:

set PATCH_PATH=%BEA_HOME%\patch_wls1001\
profiles\myCustomProfile\native

4. Restart the each Managed Server instance. Until you do so, your updates to the Node Manager configuration files and patch path variable definitions do not become effective

7 Uninstalling Maintenance Packs and Patches

At times you may want to uninstall a maintenance upgrade. You can use Smart Update to revert your system installation to an earlier version of the release, as described in the following sections:

- Important Note about Uninstalling Products

- Removing a Patch or Patch Set

- Uninstalling a Maintenance Pack

Important Note about Uninstalling Products

When you uninstall a product, any patches that may have been applied to that product are not removed. This consideration is important if patches for multiple products in a given Middleware home directory are applied to the same patch profile, and you uninstall one product but continue to use the others. When this situation occurs, products that you continue using run with patches for the product that has been uninstalled.

If you have multiple products installed in a single Middleware home directory, and you have a domain that exclusively uses only one of those products, it is a recommended best practice to use custom patch profiles for that domain so that server instances run with only the patches that have been applied to the products used by those servers. For information about pointing a domain at a custom patch profile, see Chapter 6, "Patching Individual Applications, Domains, or Servers."

Removing a Patch or Patch Set

Smart Update makes it easy to remove a patch or patch set that has been applied to a patch profile.

Note:
Installation-scoped shared archive patches cannot be removed from a custom profile: they can only be removed in the default profile. In this case, similar to the installation, the patch is removed from the default profile and all custom profiles to which it was initially applied.

To remove a patch or patch set, complete the following steps:

1. Start Smart Update.

2. In the Target Installation pane, select the product installation hosting the patch you want to remove.

3. Select the Manage Patches tab.

4. Select the patch profile containing the patch or patch set you want to remove.

5. Click the Remove button with the down arrow, located to the right of the patch you want to remove.

6. In the Remove Patch from Profile dialog, click OK.
A validation dialog box is displayed. If you are removing one patch on which another depends, a removal conflict is reported, which you must resolve before proceeding. For information about resolving patch removal conflicts, see Validation When Removing Patches. The patch removal progress is tracked in the status window. A message is displayed when the removal is complete.

7. Shut down any running WebLogic Server instances, and restart them for the patch removal to take effect.

Note:
If you remove a patch that belongs to a patch set, the entry for the patch set is removed from the listing of the patch profile contents from the Downloaded Patches panel. However, other member patches of the set that have not been removed continue to be listed in those locations.

Uninstalling a Maintenance Pack

Maintenance packs to products can be rolled back; after installing a maintenance pack to a product, such as WebLogic Server, you can roll back to the previous maintenance pack installation. For example, if you first install WebLogic Platform 9.2, and then install Maintenance Pack 1, you can later revert the installation to the initial release: WebLogic Platform 9.2.

Notes:
If you revert to an earlier installation, user-created domains may stop working because of changes made in each domain config.xml file between service or maintenance packs. If you have a backup copy of each config.xml file used with the earlier maintenance pack, you should use it after you revert the installation.
You cannot roll back to a previous version of a product if that previous version was never installed on your system.

A new operational attribute, orclguid, was added to the Embedded LDAP server as of WebLogic Server 10.3.1. Therefore, if you need to downgrade from a WebLogic Server 10.3.x installation to WebLogic Server 10.3.0, see Updating the Embedded LDAP Schema, before proceeding with the downgrade.

1. Start Smart Update.

2. In the Target Installation pane:

1. Select the Middleware home directory and installation containing the maintenance pack you want to roll back.
Maintenance packs that you can uninstall (or roll back) are displayed in the Downgrade Options section of the window.

2. In the Downgrade Options pane, select the maintenance pack that you want to uninstall and click OK.
The Oracle Uninstaller program opens and the Welcome window is displayed.

3. Click Next to proceed.
The progress of the uninstall process is reported in a status window. A message is displayed when the rollback or uninstallation is complete.

4. Click Done on the status window.
The Smart Update window is displayed. To close it, choose File > Exit.

Updating the Embedded LDAP Schema

A new operational attribute, orclguid, was added to the Embedded LDAP server as of WebLogic Server 10.3.1. Therefore, if you installed a WebLogic Server 10.3.x maintenance pack (patch set) to an existing WebLogic Server 10.3.0 to a later 10.3.x version, and then need to downgrade to the 10.3.0 installation, Oracle recommends that you upgrade the Embedded LDAP schema in your 10.3.0 installation to the schema version in the later installation. Otherwise, you may see the following LDAP error after downgrade:

LDAPException: error result (65); Missing Attributes: [], NotAllowed Attributes: [orclguid]

To upgrade the Embedded LDAP schema:]

1. Prior to downgrading to the 10.3.0 installation, save a copy of the following schema file to a temporary directory:
WL_HOME\server\lib\schema.core.xml

2. After downgrading to the WebLogic Server 10.3.0 installation, replace the schema file in the WebLogic Server 10.3.0 installation with the schema file you saved to the temporary directory.

8 Using the Command-Line Interface

This section describes the Smart Update bsu command, which you can use to apply patches, interactively or through a script, that have been downloaded into a patch download directory. When you use bsu commands in a script, you can create a mechanism for replicating a specific maintenance level of a product that is installed on multiple systems. This capability is especially valuable in production environments, in which the distribution of software updates to systems must be implemented in a controlled, reliable, and reproducible manner.

The following topics are included:

- About the bsu Command

- bsu Command Reference

- Command-Line Interface Examples

About the bsu Command

When using the bsu command, either interactively or through a script, note that this command:

- Runs the bsu script (bsu.cmd on Windows systems, bsu.sh on UNIX systems) that is located in the MW_HOME\utils\bsu directory. When running the bsu command, first change to this directory on the system from which you are running it.

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

- Can be executed from a command file (on Windows) or shell script (on UNIX).

- Contains the subset of Smart Update functionality that enables you to:

- Apply and remove patches that are located in an accessible patch download directory

- View patches that are in the download directory, applied to a product installation on the current system, or applied to a specific patch profile for the current system

- Generate reports listing the patches applied to a product installation

The bsu command can also invoke the Smart Update graphical interface and send messages to a log file.

- Can apply patches to, or view patches on, only those products installed from the system on which this command is run, as follows:

- If the current system contains a product that was installed by a different system, you cannot apply patches to that installation or view them.

- If the current system was used to install a product located on a remote-mounted disk drive, you can use the bsu command with that installation.

Therefore, the restrictions regarding the specific product installations that can be maintained through the bsu command is the same as for Smart Update's graphical interface.

- Cannot be used for the following:

- Logging in to My Oracle Support for obtaining patches and the latest patch catalog

- Creating custom patch profiles

- Locating start scripts to modify

These capabilities are available only from Smart Update's graphical interface.

Note:
If you run the Smart Update command-line interface simultaneously with the graphical interface, changes you make to patch profiles through the command-line interface are not visible from the graphical interface when you refresh the view of those patch profiles.

bsu Command Reference

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

This section describes the bsu command syntax. Square brackets appearing with a parameter argument indicate that the argument is optional.

The bsu command has the parameters and arguments listed and described in Table 8-1.

Note:
In Table 8-1, the square brackets, [..], represent arguments that are optional. For example, [-profile=profile_name] is an optional argument for the -install parameter

Table 8-1 bsu Command Parameters and Arguments

Parameter

Description

Arguments

-help

Displays a summary of bsu parameters and arguments

None.

-install

Applies specified patches to the target installation. You must specify a valid profile name.

[-patchlist=patch1[,patch2,patch3]

Specifies the identifier of each patch to be applied, represented as patch1, patch2, and patch3.

[-profile=profile_name]Specifies the patch profile to which the patches are to be applied, represented as profile_name.See the note at the end of the table.[-patch_download_dir=path]Specifies the patch download directory from which the patches are to be applied, represented as path. If you do not specify a patch download directory, the patch download directory designated in the Preference dialog box in the Smart Update graphical interface is used by default. (If none is designated in the Preference dialog box, MW_HOME\utils\bsu\cache_dir is used.)[-verbose]Displays the full set of details associated with each patch applied.[-prod_dir=path]Specifies the target installation to which the patches are to be applied, represented as path. For example, MW_HOME\wlserver_10.3 for WebLogic Server and Portal.

-gui

Starts the Smart Update graphical interface.

None.

-log

Creates a file, in the specified location, in which the corresponding bsu command logging information is to be sent.

Note: The -log parameter logs only bsu command activity, and not activity related to patches or profiles.

=path

Specifies the file name and location of the log file to be created, represented as path.

[-log_priority= {trace|debug|info|warn|error|fatal}]

Specifies the priority of log information to be captured. The default priority is debug.

-remove

Removes specified patches from the profile.

[-patchlist=patch1[,patch2,patch3]

Specifies the identifier of each patch to be applied, represented as patch1[,patch2, and patch3.[-profile=profile_name]Specifies the patch profile from which the patches are to be removed, represented as profile_name. See the note at the end of the table.[-prod_dir=path]Specifies the target installation from which the patches are to be removed, represented as path.[-verbose]Displays the full set of details associated with each patch applied.

-report

Generates a report showing the applied patches and associated file changes in a MW_HOME directory.

-BEA_HOME=path

Specifies the target installation where the patches are applied, represented as path. If no path is specified, this option generates report for all product installations.[-product_mask=regexp]Limits the report to the matching product(s), represented by the regular expression regexp.

Note: The regular expression is used to delimit multiple arguments. For example, -product_mask=WebLogic.* filters all products starting with WebLogic.[-release_mask=regexp]Limits the report to the matching product release(s), represented by the regular expression regexp.[-profile_mask=regexp]Limits the report to the matching patch profile(s), represented by the regular expression regexp.[-patch_id_mask=regexp]Limits the report to the matching patch(es), represented by the regular expression regexp.[-output_format=text|xml]Specifies the format of the report. Options available are text and xml. Default: text.[-output_file=path]Specifies the directory where the report is saved, represented as path. If no path is specified for the report output, stdout is used.

-version

Displays version information.

For example:

Oracle Smart Update. Version: 3.2.1.0

None.

-view

Displays the identifiers of patches that are either applied or in the patch download directory

[-profile=profile_name]

Displays identifiers of patches applied to the profile represented as profile_name. If you do not specify this argument, the default patch profile is used by default.

See the note at the end of the table.[-patch_download_dir=path]Displays the identifiers of patches that have been downloaded into the patch download directory represented as path. If you do not specify a patch download directory, the patch download directory designated in the Preference dialog box is used by default. (If none is designated in the Preference dialog box, MW_HOME\utils\bsu\cache_dir is used.)[-status={applied|downloaded}Displays the current status of the patches viewed. If you specify applied for this argument, bsu displays identifiers of patches that have been applied to the target installation. Use this argument, with -profile, to create a maintenance snapshot for the specific profile. If you specify downloaded, bsu displays identifiers of patches in the download directory but not yet applied

.[-verbose]Displays the full set of details associated with each patch displayed.-prod_dir=path

Displays the identifiers of patches applied to the target installation in the location represented as path.

Note:
If profile is not specified, the Default profile is used.
If the profile argument is used and an invalid profile is specified, it is not set to default; it displays the error:

$ bsu -view -status=applied -prod_dir=C:/10_WLP/wlserver_10.0-profile=profile3
The specified profile could not be found.[profile3]

Command-Line Interface Examples

This section includes the following bsu command examples:

- Installation Example

- View Patches Example

- Another View Patches Example

- Display Maintenance Snapshot

- Report of Applied Patches

Installation Example

The following command installs the patch IRZ2 from the patch download directory that has been established for the current system:

bsu -prod_dir=c:\Oracle\Middleware\wlserver_10.0 -patchlist=IRZ2 -verbose -install

When executed, the preceding command displays the following output showing that the patch was successfully applied:

Checking for conflicts.
No conflict(s) detected

Starting installation of Patch ID: IRZ2
Installing C:\Oracle\Middleware\download-dir\IRZ2.jar
Result: Success

View Patches Example

The following command displays a list of patches that exist in the patch download directory, c:\patchdir:

bsu -view -status=downloaded -prod_dir=C:\Oracle\Middleware\wlserver_10.0
-patch_download_dir=C:\patchdir

When executed, the preceding command generates a display similar to the following:

C:\Oracle\MiddlewareA\utils\bsu>bsu -view -status=downloaded
-prod_dir=C:\Oracle\Middleware\wlserver_10.0 –patch_download_dir=C:\patchdir
ProductName:     WebLogic Platform
ProductVersion:  9.2
Components:      WebLogic Platform/WebLogic Server,WebLogic Platform/Workshop
for WebLogic Platform,WebLogic Platform/WebLogic Portal
BEA_HOME:         C:\Oracle\Middleware
ProductHome:     C:\Oracle\Middleware\wlserver_10.0
PatchSystemDir:  C:\Oracle\Middleware\utils\bsu
PatchDir:    C:\Oracle\Middleware\patch_weblogic920
Profile:         Default
DownloadDir:     C:\patchdir
JavaHome:        C:\Oracle\Middleware\jrockit90_150_04
JavaVersion:     1.5.0_04
JavaVendor:      BEA
Patch Set ID:    62KY (CR293511,CR295183,CR294340,CR300742,CR286384,CR296875)
Patch ID:        7NX7 (CR999999)
Patch ID:        91T2 (CR275126)
Patch ID:        9NGH (CR999999)
Patch ID:        AF66 (CR293511,CR295183,CR286384,CR296875,CR294340,CR300742)
Patch ID:        B27Q (CR294340)
Patch ID:        EN1T (CR999999)
Patch ID:        X8JC (CR300742)
Patch ID:        Y85M (CR999999)

Another View Patches Example

The following command displays the set of patches for a target installation that have been downloaded to the system's designated patch download directory:

bsu -view -prod_dir=C:\Oracle\Middleware\wlserver_10.0 -status=downloaded -verbose

When executed, the preceding command generates a display similar to the following:

ProductName:       WebLogic Platform
ProductVersion:    9.2
Components:        WebLogic Server/Server,WebLogic Server/Server Examples,
AquaLogic Service Bus/Service Bus
BEA_HOME:           C:\Oracle\Middleware
ProductHome:       C:\Oracle\Middleware\wlserver_10.0
DownloadDir:       C:\Oracle\Middleware\download-dir
JavaHome:          C:\Oracle\Middleware\jrockit90_150_04
JavaVersion:       1.5.0_04
JavaVendor:        BEA
Patch ID:          FZN2
PatchContainer:    FZN2.jar
Checksum:          -174938558
Component:         WebLogic Server
Severity:          critical
Category:          Security
CR:                CRxxyyzz
Restart:           false
Description:       ATN fix for xxxx
Patch ID:          GWQR
PatchContainer:    GWQR.jar
Checksum:          1170817068
Component:         AquaLogic Service Bus
Severity:          optional
Category:          Multiple
CR:                CRxxyyzz
Restart:           true
Description:       One more ALSB patch

Display Maintenance Snapshot

The following command displays a maintenance snapshot of the default patch profile:

bsu -view -status=applied -prod_dir=c:\BEA\wlserver_10.0

When executed, the preceding command generates a display similar to the following:

C:\Oracle\Middleware\utils\bsu>bsu -view -status=applied
-prod_dir=C:\Oracle\Middleware\wlserver_10.0
ProductName:       WebLogic Server
ProductVersion:    10.0
Components:        WebLogic Server/Server,WebLogic Server/Server Examples,
WebLogic Server/Server
BEA_HOME:   C:\Oracle\Middleware
ProductHome:       C:\Oracle\Middleware\wlserver_10.0
PatchSystemDir:    C:\Oracle\Middleware\utils\bsu
PatchDir:          C:\Oracle\Middleware\patch_wls1000
Profile:           Default
DownloadDir:       C:\Oracle\Middleware\utils\bsu\cache_dir
JavaHome:          c:\Oracle\Middleware\jdk150_06
JavaVersion:       1.5.0_06
JavaVendor:        Sun
Patch ID:          PBLW (CR838734)

ProductName:       WebLogic Portal
ProductVersion:    10.0
Components:        WebLogic Portal/Portal Server,WebLogic Portal/WebLogic Works
WebLogic Portal/Portal Examples
BEA_HOME:   C:\Oracle\Middleware
ProductHome:       C:\Oracle\Middleware\wlserver_10.0
PatchSystemDir:    C:\Oracle\Middleware\utils\bsu
PatchDir:          C:\Oracle\Middleware\patch_wlp1000
Profile:           Default
DownloadDir:       C:\Oracle\Middleware\utils\bsu\cache_dir
Patch ID:          FJTH (CR861234)

C:\Oracle\Middleware\utils\bsu>
C:\Oracle\Middleware\utils\bsu>bsu -view -status=applied -prod_dir=C:\10_WLP_0
320\workshop_10.0
ProductName:       Workshop for WebLogic
ProductVersion:    10.0
Components:        Workshop for WebLogic Platform/Workshop,Workshop for WebLogic Platform/Workshop Examples
BEA_HOME:          C:\Oracle\Middleware
ProductHome:       C:\Oracle\Middleware\workshop_10.0
PatchSystemDir:    C:\Oracle\Middleware\utils\bsu
PatchDir:          C:\Oracle\Middleware\patch_wlw1000
Profile:           Default
DownloadDir:       C:\Oracle\Middleware\utils\bsu\cache_dir
Patch ID:          8K9T (CR873456)

Report of Applied Patches

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

The following command generates a report of patches applied to an MW_HOME, where the first character of the patch IDs is "6":

bsu -report -patch_id_mask=6.*

When executed, the preceding command generates a display similar to the following:

Patch Report
============
Report Info
Report Option
BEA_HOME ### OPTION NOT SET
product_mask.. ### OPTION NOT SET
release_mask.. ### OPTION NOT SET
profile_mask.. ### OPTION NOT SET
patch_id_mask. 6.*
Report Messages
BEA_HOME D:\Platform92\BEA_HOME
Product Description
Product Name.. WebLogic Platform
Product Version.. 9.2.0.0
Installed Components WebLogic Server, Workshop for WebLogic Platform,
WebLogic Integration, WebLogic Portal
Product Install Directory. D:\Platform92\BEA_HOME\weblogic92
Java Home.. D:\Platform92\BEA_HOME\jrockit90_150_04
Jave Vendor BEA
Java Version.. 1.5.0_04
Patch Directory.. D:\Platform92\BEA_HOME\patch_weblogic920

Profile. Default

Patch ID 6L1H
CR(s) CR285988
Description Fix P13N processing of Platform Domain Upgrade.
Intended for use with WLI 9.2
Classpath
Classpath type SYSTEM
Classpath control jar.. weblogic_patch.jar
Jar.. CR285988_920.jar
File.com/BEA/p13n/upgrade/LibraryModuleConfigProcessor.class
File. com/BEA/p13n/upgrade/P13nDatabasePlugIn.class
File. resources/p13n-upgrade.xml
File. resources/P13nCommonPlugIn-definition.xml
File. resources/portal-upgrade.xml
File. META-INF/MANIFEST.MF

Patch ID 6MK8
CR(s) CR262488
Description Allow WLI Domains to be upgraded by Domain Upgrade Wizard
Classpath
Classpath type SYSTEM
Classpath control jar.. weblogic_patch.jar
Jar.. CR262488_920.jar
File.weblogic/upgrade/domain/directoryselection/DomainDirectorySelectionPlugIn.class
File.weblogic/upgrade/domain/directoryselection/i18n_DomainDirectorySelectionPlugIn.properties
File. META-INF/MANIFEST.MF

9 Best Practices for Distributing Maintenance Updates

This section provides the following topics:

- Distributing Maintenance Patches to a Production Environment

- Providing Patches to Systems that Cannot Connect to My Oracle Support

Distributing Maintenance Patches to a Production Environment

This section discusses the following models for distributing patches to a production environment:

- Using Smart Update Scripts to Promote a Standard Maintenance Level to a Production Environment

- Creating and Distributing an Archive of the Product Installation

These models assume the following about the software maintenance that is provided for systems in the production environment:

- Updates obtained from a vendor are tightly controlled and managed. For example, they might be kept in a secure repository that few individuals in MIS are authorized to access. Copying or downloading updates into the repository might be subject to rigorous approval, scheduling, auditing, and logging procedures.

- Updates are promoted to production systems in specific stages during which they are thoroughly tested. For example, an update might first be installed on a single system, separated from the production environment, in which production applications are tested to ensure that the update works as expected and does not introduce regressions. Before being rolled out into the production environment, the updates may be tested in an intermediate staging area, where it is subject to loads that mimic expected usage in the production environment.

- When an update is introduced into the production environment itself, all systems on which the update is installed must run the updated product software at precisely the same maintenance level. For example, the domain configuration, product version, and patch level of WebLogic Server 9.1 used in all systems is identical.

- Systems in the production environment may not obtain updates from the Internet. In fact, the systems may not be connected to the Internet at all, and possibly not to the same Local Area Network shared by systems that have an Internet connection. Instead, updates are made available only from a specific location, or set of locations, in the enterprise. And the downloading of updates to the production systems are regulated by several business practices and procedures.

- The WebLogic Server instances used in the production environment are started by highly customized scripts.

Using Smart Update Scripts to Promote a Standard Maintenance Level to a Production Environment

This section describes an example scenario of how the features in Smart Update can be leveraged to distribute maintenance updates to production systems that are subject to some or all of the conditions described in the preceding paragraphs.

1. My Oracle Support has provided a private patch to solve a problem that Avitek has reported with its enterprise applications that run on WebLogic Server 9.1.

2. Bob Jones, in the Avitek MIS department, downloads the patch into the patch download directory for his system, which is set to a network disk used by MIS to store maintenance updates provided by all of Avitek's software vendors.

3. Rachel Burns works in Avitek's QA department, and her job is to test the patch on her system, which also has a WebLogic Server installation identical to the one used in the production environment. The domain configuration on Rachel's system is similar to the WebLogic domains running in Avitek's production environment. Rachel created the WebLogic Server start scripts used in the production environment, which also run on her system.
Rachel runs Smart Update in offline mode. She makes sure that the patch download directory is set to the directory used by Bob, and then she applies the patch to her WebLogic Server installation.

4. Rachel realizes that because the production systems use customized WebLogic Server start scripts, the scripts must be modified so that the classes contained in the patch are loaded into the WebLogic system classpath on her system.
Rachel adds a definition of the PATCH_CLASSPATH variable to the start script so that it points to the default patch profile, then she adds this variable to the beginning of the SET WEBLOGIC_CLASSPATH statement.

5. Rachel successfully tests the patch, and is ready to replicate the patch throughout the 20 product installations that run in Avitek's production environment. Because each production system is nearly identical, Rachel knows that she can create a script that works on every system to apply the patch.
She creates the script. Its function is very simple: it applies the patch to the default patch profile for the target installation, and it copies an updated start script into the proper location of each system.

6. Rachel uploads the patch to a patch download directory kept on a secure disk that is used by the production systems in Avitek's DMZ. She also uploads the Smart Update script and new WebLogic Server start script onto the secure disk.

7. Dagmar Kohl administers the systems in Avitek's production environment. She downloads the Smart Update script onto each production system and runs it.

8. Because of the patch contents, Dagmar knows that each server must be restarted for the patch to take effect. When the servers are restarted, the maintenance procedure is complete.

Creating and Distributing an Archive of the Product Installation

As an alternative to the scenario described in Using Smart Update Scripts to Promote a Standard Maintenance Level to a Production Environment, you can create an archive of a fully patched product image, and replicate that image throughout all the systems in a production environment. If you take this approach, note the following caveats:

- This approach is not recommended. Oracle always recommends the use of product installers for creating a product installation on a system, and of Smart Update to distribute patches.

- If a product installation includes maintenance patches that have been applied using Smart Update, you must include the following directories in the archive image, which exist at the top level of the Middleware home directory:

- patch_wls1001, and all subdirectories

- utils, and all subdirectories

Providing Patches to Systems that Cannot Connect to My Oracle Support

As mentioned in Maintaining Machines that are not Connected to My Oracle Support, Smart Update's offline usage mode enables you to install maintenance updates on systems from which it is not possible to connect to My Oracle Support. This section describes the following methods you can use for providing patches and patch sets to these systems:

- Patching an Offline System Through a Shared Patch Download Directory

- Patching an Offline System Through Removable Media

- Additional Means for Patching an Offline System

For the purposes of describing these techniques in these sections, a system that cannot connect to My Oracle Support is called an offline system.

Patching an Offline System Through a Shared Patch Download Directory

The following topics explain how to patch an offline system through a shared patch download directory:

- Requirements

- Steps

Requirements

Installing maintenance updates on an offline system through a shared patch download directory has the following two primary requirements:

- A system that can establish a connection to My Oracle Support and that has the following:

- A local installation of a product that matches the product and version of the product installed on the offline system

- A My Oracle Support user account

- A networked disk that can be accessed by both the system that can connect to My Oracle Support and the offline system

Steps

To patch a disconnected system remotely from the system with Internet access, complete the following steps using the system that has Internet access:

1. From the system that can connect to My Oracle Support:

1. Start Smart Update and log in to My Oracle Support.

2. Choose File > Preferences, and select a location for the patch download directory that is accessible by the offline system. Ensure that it is a location to which you have write permissions.

3. If you are downloading a publicly available patch, choose the product installation in the Target Installation panel that matches the product and version of the software installed on the offline system.

4. Download all required patches, as described in Chapter 3, "Downloading and Applying Patches."

2. From the offline system:

1. Start Smart Update, and select Work Offline in the Login dialog box.

2. Choose File > Preferences, and set the patch download directory to the location into which the patches were downloaded by the system that connected to My Oracle Support.

3. In the Target Installation panel, choose the target installation to which you want to apply the patches.

4. Select the Manage Patches tab, and ensure that the appropriate patch profile is selected.

5. In the Downloaded Patches panel, click Apply next to the patches you want to apply.

6. Complete the procedure for applying patches, as described in Applying and Managing Patches.

Patching an Offline System Through Removable Media

The following topics explain how to patch an offline system through removable media:

- Requirements

- Steps

Requirements

Installing maintenance updates on an offline system through removable media has the following two primary requirements:

- A system that can establish a connection to My Oracle Support and that has the following:

- A local installation of a product that matches the product and version of the product installed on the offline system

- An Oracle Support user account

- The ability to place patches onto a type of removable media that can be used by both the system connected to Oracle Support and the offline system. For example: a writable CD-ROM.

Steps

To apply patches to an offline system through removable media, complete the following steps.

1. From the system that can connect to My Oracle Support:

1. Start Smart Update and log in to My Oracle Support.

2. If you are downloading a publicly available patch, choose the product installation in the Target Installation panel that matches the product and version of the Oracle software installed on the offline system.

3. Download all required patches, as described in Chapter 3, "Downloading and Applying Patches."

4. Copy the downloaded patches onto the removable media.

2. From the offline system:

1. Mount the removable media onto the offline system.

2. Start Smart Update, and click Work Offline in the Login dialog box.

3. Choose File > Preferences and set the patch download directory as the directory the removable media containing the patches.

4. In the Target Installation panel, select the target installation to be patched.

5. Select the Manage Patches tab, and select the appropriate patch profile.

6. From the Downloaded Patches panel, click Apply next to each patch that you want to apply.

7. Complete the procedure for applying patches, as described in Applying and Managing Patches.

Additional Means for Patching an Offline System

My Oracle Support may provide you with alternative means, as appropriate, for providing you with patches if you are unable to make an online connection to My Oracle Support.

10 Known Limitations in Smart Update

This section lists the limitations that have been identified in Oracle Smart Update. Wherever possible, workarounds are provided.

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

General Issues and Workarounds

This section describes general issue and workarounds associated with Oracle Smart Update.

Smart Update 3.1 Exits with an Error if Version Strings of Products that are Not Supported by Smart Update are Present in the Registry

Smart Update 3.1 exits with an error if version strings of products that are not supported by Smart Update (such as Oracle Tuxedo) exist in the registry, and if the unsupported products and WebLogic Server are in the same Middleware home.

This error occurs, for example, when you run Smart Update on a machine that has PeopleSoft, which is dependent on Oracle Tuxedo – an product that Smart Update does not support.

To work around this issue, upgrade to Smart Update 3.2.1, which ignores version strings of unsupported products.

You can upgrade to Smart Update 3.2.1 by performing the following steps:

1. Rename the beahomelist file to beahomelist_.
For Windows, the beahomelist file is located under the ${SystemDrive}\bea folder.For Linux and UNIX, the beahomelist file is located under the ${HOME}\bea folder.

2. Invoke Smart Update.
Smart Update downloads the new version of the tool and upgrades itself automatically.

3. Close Smart Update.

4. Rename the beahomelist_ file back to beahomelist.

Smart Update Does Not Run on Apple Macintosh Machine

You cannot run Smart Update on a Macintosh machine because enough heap memory is not allocated by default.

To work around this issue, increase the Java heap memory by modifying the bsu.sh script in the MW_HOME/utils/bsu folder.

The following code illustrates the line in the script you must edit to increase the heap memory. The edited value is in bold text.

"$JAVA_HOME/bin/java" -Xms64m -Xmx256m -jar patch-client.jar $*

Exceptions are Thrown When You Use Smart Update with Node Manager Running

This issue applies only to MS Windows platforms.

Exception com.bea.plateng.patch.PatchInstallationException is thrown when you apply or remove patch using Smart Update or during an incremental installation to a Middleware home with Node Manager running.

When Node Manager is running, the process locks the file weblogic_patch.jar. As a result, the patch cannot be installed or removed successfully because it fails to update weblogic_patch.jar.

To work around this issue, shut down Node Manager when you perform incremental installation or invoke Smart Update from the same Middleware home.

Patch Application Does Not Enforce Product Check in Command-line Mode

If you have installed WebLogic Integration in command-line mode, and opted to apply patches automatically (by selecting option 1) after successful completion of the installation, the installer automatically applies patches to WebLogic Server, Workshop for WebLogic, and WebLogic Portal. The installer does not check whether WebLogic Portal is installed or not; the patches to WebLogic Portal are applied even when WebLogic Portal is not installed.

If WebLogic Portal is installed at a later point, the installer overwrites the patches but Smart Update shows the patches as applied.

To work around this issue, uninstall the patches, then install WebLogic Portal, and then apply the WebLogic Portal patches using Smart Update.

Invalidated Patches List Other Invalidated Patches as Their Replacement

When you display details about an invalidated patch, the ID of the replacement patch may be provided. But if the replacement patch is subsequently invalidated by My Oracle Support, this ID is not updated and refers to an invalidated patch.

Contact My Oracle Support for a workaround for this issue.

The Patch Profile Maintenance Snapshot Is Poorly Formatted When Viewed in Notepad

The patch profile maintenance snapshot file produced by Smart Update cannot be easily viewed in common text editors, such as Notepad. The snapshot file does not contain conventional line breaks, which results in poorly formatted columns that cannot be easily read.

To work around this issue, use a text editor such as WordPad or TextPad to view this file. You do not need to reformat this file when sending it to My Oracle Support.

Smart Update Graphical User Interface Displays an Exception in Rare Cases

In rare cases, when using the Smart Update graphical interface, the following exception may be displayed:

java.util.ConcurrentModificationException
at
java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1031)
at java.util.TreeMap$KeyIterator.next(TreeMap.java:1058)
at
com.bea.plateng.patch.gui.PatchStoreTableModel.getRowCount(PatchStoreTableModel.java:199)

This exception can be ignored.

Uninstall Component Does Not Remove Component Patches Automatically

If you uninstall any component, the patches associated with that component are not removed automatically. The patched artifacts may have been removed as part of the un-installation but the patch is still shown as applied.

To work around this issue, use Smart Update to remove the patches associated with the component before un-installation.

GUI Cannot Refresh Patches Installed from Command Line Without Restart

If you use the Smart Update graphical and command-line interfaces simultaneously, patches that you apply through the command-line interface are not visible from the GUI when you refresh the view.

To work around this issue, exit and restart the Smart Update GUI to view the new patch.

Issues with Domains Created After Rollback from WebLogic Server 10.3.2 to 10.3.1

After performing an upgrade from WebLogic Server 10.3.1 to WebLogic Server 10.3.2 using an upgrade installer or Smart Update, if you roll back to the 10.3.1 release (either with the WebLogic Server uninstaller Rollback option or via Smart Update), the following issues occur:

- WebLogic Server starts, but validation errors occur

- the Administration Console cannot be accessed (a 500 Error is displayed in the browser)

Note that these issues do not occur when upgrading from 10.3.0 to 10.3.2, and rolling back to 10.3.0.

Workaround

The only known workaround is to restore the original WebLogic Server 10.3.1 installation, if it is backed up.

Downgrade Option is Unavailable in Smart Update After Upgrade to WebLogic Server 10.3.2

If you have WebLogic Server 10.3.0 or 10.3.1 installed with the WorkShop for WebLogic component, and you use Smart Update to upgrade to WebLogic Server 10.3.2, there is no Downgrade option available in Smart Update that will allow you to roll back from 10.3.2 to the prior release.

Note:
This issue does not occur if your WebLogic Server installation does not include the Workshop for WebLogic component.

Workaround

Run the WebLogic Server uninstaller and select the Rollback option to roll back to the original WebLogic Server 10.3.0 or 10.3.1 installation. For information on how to run the WebLogic Server uninstaller, see the Installation Guide for Oracle WebLogic Server.

11 Frequently Asked Questions

This FAQ includes the following questions:

- How do I get a Support ID?

- What is a Bug or CR?

- How can I get a fix to a bug? Can I get a patch for a bug?

- How do I obtain security advisory notifications?

- What is a private patch?

- How do I get the ID for a private patch?

- How do I download just a maintenance pack?

- What products can I patch using the Smart Update tool?

- Do I need a support contract to download patches from My Oracle Support?

How do I get a Support ID?

To obtain a My Oracle Support account, go to the Oracle Support site, http://www.oracle.com/support/index.html, and click My Oracle Support Login.On the My Oracle Support page, follow the instructions to register as a new user.

What is a Bug or CR?

A bug is a defect in the existing code or functionality not performing as documented. CR is the BEA-equivalent term for bug.

How can I get a fix to a bug? Can I get a patch for a bug?

Use the Smart Update tool to view, download, and apply available patches. If a patch is not available from Smart Update to fix your problem, open a case with My Oracle Support.

How do I obtain security advisory notifications?

Go to the Critical Patch Updates and Security Alerts page, http://www.oracle.com/technology/deploy/security/alerts.htm to see an updated list of advisories and the recommended remedies or patches. You may also register at http://www.oracle.com/technology/deploy/security/securityemail.html to receive notification of security advisories.

What is a private patch?

Private patch is one that Oracle Support makes available to you as part of a custom maintenance solution, and is not generally available from the My Oracle Support Repository to all customers.

How do I get the ID for a private patch?

Oracle Support sends the patch ID and passcode to you through e-mail.

How do I download just a maintenance pack?

Maintenance packs are available individually for download to users with a valid maintenance contract. You can obtain a maintenance pack in either of the following ways:

- Use the Maintenance Pack Update component of Smart Update to view and download a maintenance pack when it is available for the product. This is the recommended method.

- Log in to the My Oracle Support Web site, http://www.oracle.com/support/index.html, and choose Patches & Updates from the menu bar. Select the Oracle product and the version and maintenance pack you want. See "Downloading an Upgrade Installer From My Oracle Support" in Oracle WebLogic Server Installation Guide for detailed instructions.

What products can I patch using the Smart Update tool?

See Products Supported by Smart Update Version 3.2.1.

Do I need a support contract to download patches from My Oracle Support?

You do need a support contract to obtain a My Oracle Support account. You can download patches and updates only if you have a My Oracle Support account.

A Smart Update Quick Reference

This section guides you through the steps to complete three basic tasks and describes the icons and labels used in the graphical interface:

- How to Download and Apply a Private Patch

- How to Generate a Maintenance Snapshot

- How to Create a Custom Patch Profile

- Smart Update GUI Glossary

How to Download and Apply a Private Patch

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

This section provides a quick-reference aid that guides you through the steps of retrieving and applying a private patch that My Oracle Support has provided for you.

To retrieve and apply a private patch, complete the following steps.

1. Launch Smart Update:
Windows:

From the Start menu, choose Start > Programs > Oracle WebLogic > Smart Update.

UNIX:

1. Change to the MW_HOME/utils/bsu directory.

2. Enter the bsu.sh command.

2. Log in to My Oracle Support:

3. In the Smart Update main window, in the panel labeled Target Installation, select the Oracle product installation for which you are downloading a private patch.

4. Select the Get Patches tab.

5. Choose Patches > Retrieve Private, enter the patch identifier and passcode, and click Download.

6. When prompted whether to check the patch for conflicts before download, click No, continue with the download and check for conflicts later, and click OK.

7. Select the Manage Patches tab.

8. In the Downloaded Patches panel, click Apply next to the listing of the private patch you downloaded.
When you apply a patch, the patch is automatically validated against the other patches that have been applied to the target installation. If no conflicts are detected, Smart Update displays a dialog box. Click OK.

How to Generate a Maintenance Snapshot

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

Smart Update provides a mechanism for capturing information about your Oracle product installation that you can send to My Oracle Support when reporting a problem. This information is called a maintenance snapshot. This section guides you through the steps of creating a maintenance snapshot.

To generate a maintenance snapshot, complete the following steps.

1. Launch Smart Update:
Windows:

From the Start menu, choose Start > Programs > Oracle WebLogic > Smart Update.

UNIX:

1. Change to the MW_HOME/utils/bsu directory.

2. Enter the bsu.sh command.

Note:
You do not need to log in to My Oracle Support to generate a maintenance snapshot.

2. In the Smart Update main window, in the panel labeled Target Installation, select the Oracle product installation with which you are reporting a problem.

3. Select a patch profile in the Manage Patches tab.

4. Choose Patches > Patch Profiles > Save Snapshot.

5. In the Save Snapshot dialog box, enter a file name for the maintenance snapshot, and click OK.
The maintenance snapshot is a simple ASCII text file.

6. Send the maintenance snapshot file to My Oracle Support. Use of e-mail is preferred. But you can print the file and send it through postal mail, if appropriate.

How to Create a Custom Patch Profile

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

If you want to limit the scope of a class or library path patch to a specific domain or server, you need to:

1. Create a custom patch profile, and apply the patch to it.

2. Modify the start script for the corresponding domain or server to add a reference to the custom patch profile.

This section provides a quick-reference aid that shows how to complete these steps, and uses the example of a test engineer who has downloaded a patch and plans to test the patch in a QA domain before incorporating the patch into a production domain.

To create a custom patch profile and point a domain or server at the patches applied to the profile, complete the following steps:

1. Start Smart Update, log in to My Oracle Support, and select the Oracle product in the Target Installation panel.

2. Download the patch from My Oracle Support into the designated patch download directory.

3. Create a custom patch profile to which the patch is to be applied, using the following steps:

1. Choose Patches > Patch Profiles > New.

2. Assign a name for the custom patch profile, and specify the initial set of patches you want in the custom patch profile by cloning the contents of another existing patch profile that exists for the target installation.
Example: The test engineer wants to run the QA domain at the same patch maintenance level as the production system, but with the addition of the patch downloaded in step 2. Therefore, the engineer creates the custom patch profile, QADomainProfile, and clones the contents of the default patch profile to it. Later, the engineer will apply the downloaded patch to this custom patch profile.

Note that any existing installation-wide patches that have been applied to the target installation are included in the custom patch profile by default.

After you click Create, the custom patch profile is displayed in a tab adjacent to the tab for the default patch profile.

4. Apply patches to, or remove patches from, the custom patch profile, as appropriate.
Example: The test engineer now applies the patch that was downloaded in step 2 to the QADomainProfile custom patch profile.

5. Before running the Start Script Editor, make backup copies of any scripts you plan to modify.

Note:
Start Script Editor is not applicable for OSGi-based products such as Oracle Enterprise Repository.

6. Choose Patches > Patch Profiles to open the Start Script Editor. You can modify the appropriate start script so that it references patches in the custom patch profile.

7. In the Start Script Editor dialog box, choose the custom patch profile you created, the product for which you want to edit the script, and then click Open.

8. Open the appropriate start script so that the domain, cluster, or server can run with the patches in the custom patch profile. In the following table, domain_home represents the path to the domain root directory.

To point the following at patches applied to the custom patch profile

Open the following script

Domain

Windows:

domain_home\bin\setDomainEnv.cmd

UNIX:

domain_home/bin/setDomainEnv.sh

All WebLogic Server instances in the domain

Windows:

domain_home\bin\startWebLogic.cmd

UNIX:

domain_home/bin/startWebLogic.sh

All Managed Servers

Windows:

domain_home\bin\startManagedWebLogic.cmd

UNIX:

domain_home/bin/startManagedWebLogic.sh

One server instance

Windows:

domain_home\bin\startServerName.cmd

UNIX:

domain_home/bin/startServerName.sh

Example: Because the test engineer needs to point the QA domain to the custom patch profile, the engineer opens the setDomainEnv.cmd script, which sets the environment for all servers in that domain only. Unless you need to limit the scope of a patch to a specific server instance, we generally recommend that you choose the setDomainEnv for pointing to custom patch profiles.

9. In the appropriate start script, create the environment variables that reference the classes, extension directories, or library path patches in the custom patch profile to which you want the script to point.
Patch classpath and other environment variables are set for each product individually. You must set the appropriate variables for each product similar to the variables set in WL_HOME\common\bin\setPatchEnv.cmd (Windows) or WL_HOME/common/bin/setPatchEnv.sh (UNIX). These environment variables are listed in the following table.

To reference the following patch

Define the following environment variable so it points to the patches in the custom patch profile

Patch JAR containing classes to be interested into the WebLogic system classpath

Environment variables to define:

PATCH_CLASSPATH

Example:

set WLS_PATCH_CLASSPATH=
%BEA_HOME%\patch_wls1030\profiles\NewProfile
\sys_manifest_classpath\weblogic_patch.jar
if "%PATCH_CLASSPATH%" == ""
set PATCH_CLASSPATH=%WLS_PATCH_CLASSPATH%;%WLW_PATCH_CLASSPATH%;%WLP_PATCH_CLASSPATH%

Patch JAR containing classes to be inserted into the classpath of an application deployed on WebLogic Server

Environment variables to define:

WEBLOGIC_EXTENSION_DIRS

Example:

set WEBLOGIC_EXTENSION_DIRS=
%BEA_HOME%\patch_wls1030\profiles\NewProfile
\sysext_manifest_classpath

Native file to be inserted into the system library path (UNIX)

Environment variables to define:

PATCH_LIBPATH

Example:

PATCH_LIBPATH="${BEA_HOME}/patch_wls1030/profiles
/NewProfile/native"

Native file to be inserted into the system library path (Windows)

Environment variables to define:

PATCH_PATH

Example:

set PATCH_PATH=
%BEA_HOME%\patch_wls1030\profiles\default\native

The figure example shows the snippet used to change the setDomainEnv.cmd script.

10. Ensure that any patch path variables you add to a start script precedes an invocation to one of the other environment scripts. For example, if you add a patch path variable definition to the setDomainEnv script, ensure that it is placed before the invocation of the commEnv script.
If you use custom scripts in your environment that do not invoke the WL_HOME\common\bin\commEnv script, or any of the other default scripts produced by the Configuration Wizard, you also need to modify the statements in your scripts that set the class and library paths for your environment so that the environment variables you have defined are properly inserted into those statements.

For example, to set the WebLogic system classpath so that patch JARs in a custom patch profile supersede same-named classes appearing later in the classpath, add the PATCH_CLASSPATH variable as follows, shown in bold:

set WEBLOGIC_CLASSPATH=%PATCH_CLASSPATH%;%JAVA_HOME%\lib\tools.jar;
%WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\weblogic.jar;
%WL_HOME%\server\lib\webservices.jar

11. Click Save.
For the patch to go into effect, each server instance that uses the patch must be restarted.

12. If you subsequently decide to change the scope of a patch so that a different domain or server uses the patch, or so that all servers and domains that run on an installation use the patch, update the appropriate patch profile.
Example: When the test engineer approves the patch that has been tested in the QA domain, the patch can then be promoted for use in the production domains. To promote the patch, the test engineer does the following:

1. Runs Smart Update, and selects the product installation used by the production domain.

2. In the Manage Patches tab, selects the default patch profile, and applies the patch.

3. Restarts the servers in the production domain.

Smart Update GUI Glossary

Table A-1 provides a key to the graphical symbols and labels used throughout the Smart Update graphical interface.

Note:
Starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME.

Table A-1 Smart Update Graphical Interface

Screen or Panel

Symbol

Description

Target Installation

Represents a Middleware home directory, which may contain multiple Oracle products. When you create a maintenance snapshot, you must select the appropriate Middleware home directory.

Note that the Smart Update graphical interface can display only those Middleware home directories for products that were installed by the current system. Middleware home directories on remote-mounted disks are visible only if installed from the current system.

Target Installation

Represents a product home directory. For example, WebLogic Server, or Oracle Service Bus.

Target Installation

Represents a specific installation of a product, called the target installation. For example, WebLogic Server Release 9.1.

A specific installation must be selected to do the following:

- View or download a publicly available patch or patch set

- Apply or remove a patch or patch set

- Create or remove a custom patch profile

Get Patches tab

Enables you to view publicly available patches and patch sets for the selected target installation. Also enables you to view contents of current patch download directory.

Get Patches tab

Indicates an individual patch. Click this icon to get detailed information about the corresponding patch.

Get Patches tab

Indicates a patch set, which comprises multiple patches. Click this icon to get detailed information about the constituent patches.

Get Patches tab

When checked, enables corresponding publicly available patch or patch set to be downloaded. You may make multiple selections simultaneously. To begin the download, click Download Selected.

Downloaded Patches panel

Displays contents of patch download directory. When Get Patches tab is selected, contents of download directory for selected target installation is displayed. When Manage Patches tab is selected, only patches not yet applied to a given profile are displayed.

Downloaded Patches panel

When green arrow is clicked, applies corresponding patch or patch set to current patch profile. (Patches and patch sets can be applied only when the Manage Patches tab is selected.)

Manage Patches tab

Displays contents of each patch profile, which is the set of patches applied to the currently selected target installation. You apply and remove patches and patch sets from the Manage Patches tab.

Note: To apply a patch or patch set and add it to the current profile, click Apply next to that patch or patch set in the Downloaded Patches panel.

Manage Patches tab

Displays the set of patches and patch sets scoped to the entire installation in a given Middleware home directory, which corresponds to the currently selected target installation.

If you have created additional patch profiles, called custom patch profiles, each has its own tab adjacent to the Default Profile tab.

Manage Patches tab

When the red arrow is clicked, the corresponding patch or patch set is removed from the target installation and from the profile. (Removed patches or patch sets are re-listed in the Downloaded Patches panel when the patch profile contents are displayed from the Manage Patches tab.)

Patch Application Validation dialog box

Displays conflicts that have occurred when applying a patch or patch set, identifying the patches that conflict with the one, or ones, being applied. The conflict conditions that can occur when applying a patch or patch set are described below.

Patch Application Validation dialog box

The selected patch cannot be applied until one or more other patches are first applied. To resolve this conflict:

1. Note the identifiers of the prerequisite patches.

2. Click Cancel, download and apply the prerequisite patches, then apply the selected patch

Patch Application Validation dialog box

The selected patch requires that you first remove one or more other patches that have been applied. To resolve this conflict:

1. Note the identifiers of the patches that must be removed.

2. Click Cancel and remove the identified patches.

3. Download and apply the selected patch.

4. Re-apply the patches removed in step 2.

Patch Application Validation dialog box

The selected patch cannot coexist with one or more other patches that have been applied To resolve this conflict, you must choose which patch you want applied to the target installation.

Glossary

BEA_HOME directory

Root directory into which Oracle software products are installed, represented by the environment variable BEA_HOME.

Note that starting from the Oracle Fusion Middleware 11gR1 release, MW_HOME is the new term for BEA_HOME (default is C:\Oracle\Middleware), and WL_HOME is the term used for WebLogic Server home (default is C:\Oracle\Middleware\wlserver_version.

bsu command

Command for running the Smart Update command-line interface. To run the command-line interface, you must first change to the MW_HOME\utils\bsu directory. See Chapter 8, "Using the Command-Line Interface."

custom patch profile

A patch profile the user can create in addition to the default patch profile. The use of a custom patch profile provides a way to scope a set of patches to a subset of the servers that run on a specific Oracle product installation; for example, an individual domain, cluster, or server. Custom patch profiles are described in Chapter 5, "Activating Applied Patches in Your Installations and Applications."

dependency violated

Conflict reported when you attempt to remove a patch upon which an existing patch depends.

installation-level patch directory

Directory created by Smart Update that contains patch JAR files, native patches, profile subdirectories, the patch registry, and the patch manifest JAR files.

invalidated patch

Patch that has been superseded or deprecated by My Oracle Support. Smart Update automatically notifies you if any invalidated patches are detected in your patch download directory. If you have applied an invalidated patch, Smart Update highlights it in among the entries in your patch profile. You can click on the patch icon to get information about replacing an invalidated patch, when a replacement is available.

maintenance pack

A maintenance pack is an update to an existing release that includes solutions to known problems and other product enhancements. A maintenance pack is not a replacement for an installation of the Oracle product, but a package of changes and additions to it.

Service packs are replaced by maintenance packs starting with WebLogic Platform 9.2 Maintenance Pack 1.

maintenance snapshot

Text file you can generate using Smart Update that contains details about the current maintenance level of a target installation for a specific patch profile.

module patch

Patches that update common modules and product-specific modules.

mutually exclusive

Conflict that is reported when a patch you have selected to download or apply cannot coexist with an existing patch for the target installation. The identifier of the existing patch causing the conflict is provided.

MW_HOME directory

Root directory into which Oracle software products are installed, represented by the environment variable MW_HOME.

native artifact file

Operating system-specific file, which may be a binary file or other resource.

out of sequence

Patch conflict reported when you are attempting to download or apply multiple patches in the wrong sequence. When this conflict is reported, the proper sequence for the selected patches is provided.

patch manifest JAR

File that references patch JARs that exist in the in the MW_HOME\patch_wls1001\patch_jars directory

passcode

Alphanumeric string provided by Oracle Support that you use, with a patch identifier, to obtain a private patch.

patch

Between maintenance packs, patches are issued to provide bug fixes for individual components. A patch does not provide product enhancements.

patch backup manifest

File, stored in the MW_HOME\patch_wls1001\backup directory, that contains files that have been replaced as a result of having applied a patch. This directory holds files required to restore an earlier patch maintenance level on your system.

patch conflict

Compatibility problem that Smart Update has detected between the patch you have selected to download, apply, or remove and the other patches that have been applied to the target installation.

patch container

File that you download from Oracle Support that is kept in the patch download directory. Contains patch content and metadata about that patch that is used for validation.

patch identifier

Unique identifier for a patch. Use of a patch identifier is required for obtaining private patches.

patch JAR file

JAR file containing classes to be inserted into a classpath; for example, in the WebLogic system classpath, or the classpath of an application deployed on WebLogic Server. Patch JAR files are placed in the patch_jars subdirectory of the installation-level patch directory. For more information about patch JAR files, see Structure of the Installation-Level Patch Directories.

patch profile

Set of patches that have been installed in a specific Oracle product installation and that serves as a mechanism for Smart Update to validate patches being applied.

patch set

Set of multiple patches made available for download and installation as a single entity. Patch sets enforce the sequence in which member patches are applied to the target installation; however, individual patches within a set may be selectively removed. Patch sets can be created from multiple, existing patches.

prerequisite not met

Conflict that may be reported when downloading or applying a patch. This conflict occurs when you are attempting to download or apply a patch that requires other patches be installed first. Identifiers of prerequisite patches are displayed when this conflict is reported.

private patch

Patch that Oracle Support makes available to individual users based on their support requirements. A private patch may be unique to a given user.

publicly available patch

A patch that My Oracle Support makes available anyone with a valid support contract. From the Smart Update Get Patches tab, you can view and obtain detailed information about publicly available patches for a specific Oracle product that is installed on your system.

support ID

ID of the user account you obtain when you register with Oracle. For more information, see Obtaining a My Oracle Support Account.

target installation

The currently selected Oracle product installation in Target Installation panel of Smart Update.

validation

The process of determining if a patch has a conflict with other patches that are applied to the target installation.

Oracle Legal Notices

Copyright Notice

Copyright © 1994-2014, Oracle and/or its affiliates. All rights reserved.

Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Alpha and Beta Draft Documentation Notice

If this document is in preproduction status:

This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.