The patch application process has been improved with the Carbon 4.2.0 release, to automate and verify the patch application process. There will be a separate directory with this release, named servicepacks in the <CARBON_HOME>/repository/components/ directory to add service packs that are officially released by WSO2.
The servicepacks application process is identical to the normal patch application process. Any servicepackXXX that needs to be applied to the system, needs to be put into the above servicepack directory; while servicepackXXX needs to be removed from the service directory when that specific service pack is reverted.
In the previous patch application process whenever a patch is added or removed from <CARBON_HOME>/repository/components/patches directory it was required to provide -DapplyPatches parameter with server startup command to start the patch application process. However, in the new improvements it is no longer required to provide -DapplyPatches parameter with server startup command. The patch application process will get automatically started when the server starts up provided there are any changes in either the <CARBON_HOME>/repository/components/servicepacks or <CARBON_HOME>/repository/components/patches directories. Thereafter, it will verify all the latest JARs in servicepacks and patches against JARs in the plugin directory by comparing MD5 of JARs. Please see the patch application flow figure below.
All patch related logs will be logged to patches.log file in <CARBON_HOME>repository/logs/ directory. All applied service packs and patches list can be found in <CARBON_HOME>/repository/components/default/configuration/prePatched.txt file.
It is not recommend to change data in this file as the patch application process gets the pre-patched patch list from this file and compares it with the patches available in the servicepack and patches directory. If you change data in this file, you will get a startup error while applying patches.
As the whole, the patch application log is available in a single place, simply follow the patch application process history and log messages that are self descriptive.