• Savidu Dias

Resolving Conflicts in WSO2 Updates 2.0

WSO2 is the world’s #1 Open Source Integration Vendor. If you are familiar with WSO2’s lineup of products, you may also be interested in learning more about how you can update these products and be up-to-date with their latest and greatest features.


In October of 2020, WSO2 announced the release of its all new Updates 2.0, which is the successor to its old update model WUM (WSO2 Update Manager). If you’re interested in learning more about Updates 2.0, you can read its documentation here.


One of the major advantages of Updates 2.0 in comparison to its predecessor WUM is that the new update model allows its users to apply updates directly on top of their deployment setup. While applying updates on top of a setup, the update client has the capability of merging the changes from an update on top of any customized changes.


However, there are cases where the tool is not able to merge file changes over customizations. In such cases, the update client throws conflicts indicating that it was not able to merge the changes from the update on top of the customizations.


In this post, I will first take you through what exactly conflicts are by intentionally producing a conflict, and then I will show you how we can resolve this conflict.


Producing a Conflict


To show how we can produce a conflict, I will download a product pack of WSO2 API Manager 4.0.0 from the WSO2 Website and apply an update on the pack.

After downloading the zip file from the website, I will unzip it, navigate to the bin directory and run the new Update client.

When you run the tool for the first time, it will request for the credentials of your WSO2 subscription. If you do not have a WSO2 Subscription yet, you can simply hit the return key and go on ahead with a free trial for updates.


Additionally, it is very likely that the tool will update itself when running for the very first time. In that case, you can re-run the update tool command and apply updates to your pack.

After the update has been applied successfully, we are going to get the list of files that were updated. In order to find out which files were updated, we can visit the WSO2 Update Information Portal. After logging in with your subscription credentials, you will be presented with a list of WSO2 products that you have taken updates for.

In the product that we just updated, click on the button under “Already Installed Updates” to view details of the updates that have already been installed for API Manager 4.0.0.

Thereafter, select the “Download PDF” button at the top of the page to download details of all of the updates that you have applied to the pack.


If you do not have a WSO2 subscription, you can navigate to the Update Levels page in the portal and provide the update levels manually and select the “Download” button to download the update PDF file.


We can get details of all of the files that have been updated towards the end of the PDF file.

What we need to do now is to compare one of the updated files with its original file by getting a diff. For that, I will first copy the content of a file in the pack that we have already updated. Let’s take the repository/components/tools/forget-me/conf/sql/apim/am-api-comments.sql file as an example. After copying the file content, I will paste it into a diff checker.

Thereafter, I will revert the changes from the update and go back to the initial pack by running the update client tool with the --revert flag.

Now we will copy the content of the file before taking the update, and generate a diff of the file before and after applying the update.

Now that we know exactly where the changes are going to be, let’s produce a conflict on purpose.


As we can see, the change to the SQL file from the update is a change to the column name. If we want to generate a merge conflict to this change intentionally, we can make a slight change to the column name in the SQL file.

I have done so by changing the column name in line 2 from “COMMENTED_USER” to “COMMENTED_TEST_USER”. The purpose of this change is to demonstrate conflicts. Therefore, it does not matter if this breaks the functionality of the product.


After making this change, I will apply the update again, and this time, I will get a message indicating that I have encountered a merge conflict in the file I have made changes to.

And that is how we have intentionally produced a conflict while running updates to a WSO2 product. Now comes the fun part. Let’s see how we can resolve this conflict.


Resolving a Conflict


If we head on over to the parent directory of the “am-api-comments.sql” file that the conflict was encountered in, and list the files in that directory, we would notice that there are 2 new files for “am-api-comments.sql” under different extensions.

  • am-api-comments.sql.original - file before making customizations

  • am-api-comments.sql - the customized file

  • am-api-comments.sql.new - new file from the update

We can get diffs between these files and get a sense of the changes we have done, changes from the update, and the changes we must do.

  1. Diff between am-api-comments.sql.original and am-api-comments.sql - Custom changes we have made

  2. Diff between am-api-comments.sql.original and am-api-comments.sql.new - Changes from the update

By taking these two diffs into account, we can create another file in the same parent directory that contains changes from the updates as well as our customizations. Once the changes are finalized, we will name this file am-api-comments.sql.final.


After saving the file, we need to run the update tool one last time; this time with the --continue flag.

And there you go! We have successfully resolved our conflict and updated our pack of API Manager 4.0.0 with the customized changes.

45 views0 comments