This documentation is for WSO2 Carbon 4.4.1. View documentation for the latest release.
WSO2 Patch Application Process - Carbon 4.4.1 - WSO2 Documentation
Due to a known issue do not use JDK1.8.0_151 with WSO2 products. Use JDK 1.8.0_144 until JDK 1.8.0_162-ea is released.
Skip to end of metadata
Go to start of metadata

WSO2 has introduced the WSO2 Update Manger (WUM), which is a command-line tool that allows you to update your product with the latest available patches and enhancements. You can see if your product version is supported by WUM from here, and if it is supported, follow the instructions in Updating your WSO2 product to get the latest patches. 

The patch application process described below guides you on how to manually apply security patches to Carbon 4.4.x-based products (if your product version is currently not supported by WUM). 

Applying patches to the product

You can apply patches to your product in two ways:

  • Apply each patch individually.
  • If you want to apply multiple patches, create a collective patch and apply it to the product. A collective patch is a single patch that includes all the JAR files from the individual patches that should be applied.

Follow the steps given below to apply an individual patch or a collective patch to the product:

  1. Copy the patches to the <PRODUCT_HOME>/repository/components/patches directory.
  2. Start the Carbon server. The patches will then be incrementally applied to the plugins directory.

    Before applying any patches, the process first creates a backup folder named patch0000 inside the <PRODUCT_HOME>/repository/components/patches/ directory, which will contain the original content of the <PRODUCT_HOME>/repository/components/plugins/ directory. This step enables you to revert back to the previous state if something goes wrong during operations.

Prior to Carbon 4.2.0 version, users were expected to apply patches by starting the server with -DapplyPatches. Now, you do not have to issue a special command to trigger the patch application process. It starts automatically if there are changes in the <PRODUCT_HOME>/repository/components/patches directory. It verifies all the latest JARs in the patches directories against the JARs in the plugins directory by comparing the MD5s of JARs.

Verifying the patch application

After the patch application process is completed, the patch verification process ensures that the latest service pack and other existing patches are correctly applied to the <PRODUCT_HOME>/repository/components/plugins/ folder.

  • All patch related logs are recorded in the <PRODUCT_HOME>/repository/logs/patches.log file.
  • The <PRODUCT_HOME>/repository/components/patches/.metadata/prePatchedJARs.txt meta file contains the list of patched JARs and the md5 values.
  • The patch directory information of all the applied patched will be in the <PRODUCT_HOME>/repository/components/default/configuration/prePatchedDir.txt file.

    Do not change the data in the <PRODUCT_HOME>/repository/components/default/configuration/prePatchedDir.txt file. The patch application process gets the pre-patched list from this file and compares the list with the patches available in the patches directories. If you change the data in this file, you will get a startup error when applying patches.

  • No labels