Patching with Liferay considering custom modules for collisions

Suyash Bhalekar
Suyash Bhalekar
2 Minute Read

I spent some time understanding the patching tool and I found that the patching tool's store option is very useful when it comes to comparing patches with custom modules.

Use case :

You have Liferay Portal instance with fixpack say liferay-fix-pack-de-89-7010.zip and hot fix say liferay-hotfix-7477-7010.zip. And now you come across a scenario where you found a liferay bug. You raise a ticket to Liferay and Liferay provides a hotfix on top of your current stack.
So say Liferay has provided the hotfix "liferay-hotfix-7478-7010.zip" which contains a fix for the bug you reported to Liferay.
Now to apply this patch you can simply use Liferay's patching tool to do so. I am not gone list steps here since you have good documentation provided by Liferay or you might be knowing by now :)

So far so good. Till now we have not considered the scenario where you have a custom module which is trying to override the Liferay's sources.
So now let's bring back this scenario. I have developed a module to override the OOTB Asset Publisher's view.jsp

When Liferay provided the liferay-hotfix-7478-7010.zip, it contains changes in sources as compared to liferay-hotfix-7477-7010.zip.
Now it is easy to apply a new patch with a patching tool. But wait, what about your custom changes. You copied the sources for your custom development or I would say your base source for custom development was a complaint to the source of hotfix "liferay-hotfix-7477-7010.zip"

There might be a possibility that Liferay's hotfix (liferay-hotfix-7478-7010.zip) has modified the OOTB Asset Publisher's view.jsp

So now for your custom development to be compliant with this hotfix you need to consider the view.jsp provided by liferay-hotfix-7478-7010.zip as the base source.

We consider only one scenario but in the actual project, we have many such modules. And now to check their complaint it's a nightmare job.

Solution :

Till I guess 6.2 or 6.1, Patching-tool's list-collisions use to do the job. In order to achieve this in DXP, we need a few more steps which are as follows

1) We assume that you have all your custom changes deployed and you have installed fix pack "liferay-fix-pack-de-89-7010-src.zip" along with hotfix "liferay-hotfix-7477-7010.zip"

2) Now you need to store your current state in order to make it available later to compare. so run below command

patching-tool.bat store add <descriptive-name>

patching-tool.bat store add dxp70-fix-89-with-hotfix-7477

This will take some time. Also, one thing to note here is that in the patches folder you have to make sure that you are using fixpack zip which contains sources as well.
So whenever you download the fixpack from liferay's site make sure you download with the source. For example, in our scenario, it would be liferay-fix-pack-de-89-7010-src.zip
It is well present in dropdown provided by Liferay during download.

3) With step 2, our current state is saved as "dxp70-fix-89-with-hotfix-7477" under patching-tool's store folder.

4) We now install the hotfix liferay-hotfix-7478-7010.zip

5) We then run below command to capture the collisions with respect to our custom plugins if any

    patching-tool.bat diff collisions html dxp70-fix-89-with-hotfix-7477

This will generate the diff in Html format since we mention "html". The output HTML is stored in patching-tool's diff folder.

Few important points to note here are that collisions option work with only one parameter of stored state like "dxp70-fix-89-with-hotfix-7477" we provided in the above command. However, to capture the differences between two patches we can store the state of both the patches post applying and then compare with

patching-tool.bat  diff  html  dxp70-fix-89-with-hotfix-7477  dxp70-fix-89-with-hotfix-7478

So to compare two patches,

You apply patch1 and store state
patching-tool.bat store add state1

You now apply patch2 and store state
patching-tool.bat store add state2

Now to compare,
patching-tool.bat diff html state1 state2

You might come across memory issues while running above command so to avoid you can edit patching-tool.bat/sh and update memory parameter to run the patching-tool.jar

Page Comments
Lee Jordan
5 Years Ago

This is a great post! Thank you for sharing.

 

From my own experience and I know what the response will be to this, patching is too broad. If Liferay is modular we should be able to "get the fix pack for Alloy Editor", or "apply the patch for message boards". We can't. We never have been able to, none of us have.

 

I find the time it takes to successfully patch a Liferay Instance that has been touched by customization is in the order of at least 3 to 4 months. At times we use beyond compare to run say our " JSP file" against Fixpack 93's file to see what Liferay changed. What can happen is that Liferay make a fix or improvement but our file overrides Liferay's, so we must work to understand the change. That in itself is hindered when we go to a pull request and it 404's. 

 

Patching is made virtually useless by the approach that Liferay take to overriding, that in order to "change a file" we must take a copy of the file and build our own module for it. The same in the theme too, if you want to tweak a CSS file, you must take that from build into src. The problem in the theme there are hundreds of files.

 

Every "override" adds time to review and implement a fixpack release.

 

In the theme directories I have flatly refused to override Liferay's theme files, instead I import my own SCSS files that will not clash with Liferay's, when there is a clash I understood deeply what I did in the first place and because all I need to do is review what liferay changed, I can make my adjustments faster.

 

All that to say ... A fix pack touches the entire portal. Often the Jira tickets lack details that can allow us to understand the changes, therefore making verification of fixes almost impossible. If we don't pay attention and blindly patch, we can find Elastic search breaks, the asset publisher stops working, that's my first clue Elastic search broke.

 

And again all that to say, if the entire portal wasn't being patched, we could focus on fixes, take less time to patch and get a more stable release to production where things are actually getting fixed instead of getting more broken and more unstable.

Please sign in to reply.
Lee Jordan
5 Years Ago

To give complete technical feedback too, I've noticed that some changes will say change a method name, further on down in the imported files. Personally I'm a front end developer and I routinely have to look at Java code. I don't understand it, I need to take a shower afterwards ... but I can read code regardless.

 

What I can't do is go through a maze of API's and Javadocs to understand what changed and why, so that I can fix the if or case statement in the the asset publisher view file say. And again if your project has deviated from vanilla Liferay, it's very difficult to patch which should alarm Liferay more than it does us the folks trying to keep in step with changes.

 

If you think about it we're as much custodians of Liferay's reputation as Liferay themselves are. If not in terms of security issues which can harm both of us then in terms of reliability and stability.

 

Liferay is too hard to patch.

Please sign in to reply.

Related Assets...

No Results Found

More Blog Entries...

Ben Turner
October 21, 2025
Michael Wall
October 14, 2025
YOGESH CHANDRA
October 08, 2025