Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: Liferay Upgrade process: How to update data using service from same mod
Dear Community,
I have been used for the Liferay 6.2 upgrade process for few years and then Liferay DXP comes with new way of doing things. Nice, let's follow the following article : https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-1/creating-an-upgrade-process-for-your-app
In my case, I don't need to update the database schema itself but populate the table with default data. And I wish I could use the service which implementation is available in the same module...
The problem is that the service (@Reference) cannot work until the upgrade is complete: it points to null (XXXLocalServiceUtil.dowhatever() -> NullPointerException)
It looks like the upgrade expects only SQL queries but not service call. I could implement data populating using an Activator but in that case, the same code would apply each my module would be restarted. And I would like this code runs only once, when upgrading.
How can I acheive my requirement ?
Thank you,
I have been used for the Liferay 6.2 upgrade process for few years and then Liferay DXP comes with new way of doing things. Nice, let's follow the following article : https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-1/creating-an-upgrade-process-for-your-app
In my case, I don't need to update the database schema itself but populate the table with default data. And I wish I could use the service which implementation is available in the same module...
The problem is that the service (@Reference) cannot work until the upgrade is complete: it points to null (XXXLocalServiceUtil.dowhatever() -> NullPointerException)
It looks like the upgrade expects only SQL queries but not service call. I could implement data populating using an Activator but in that case, the same code would apply each my module would be restarted. And I would like this code runs only once, when upgrading.
How can I acheive my requirement ?
Thank you,
We stop using XxxLocalServiceUtil classes, period. Those are only for legacy code coming forward, but they should be abandoned as soon as possible.
For your upgrade process, you then have an @Reference to the XxxLocalService. It will be injected when the service is ready and then your upgrade process will be ready and everything will happen in a smooth sequence...
But wait, you'll say, the upgrade processes are not components and therefore cannot have @Reference injections. This is totally true, but the upgrade processes are added by the upgrade registrator which is, in fact, a component that can have @Reference injections.
So the registrator needs to have all of the @Reference values for all of your upgrade processes, then it can pass them in while creating the upgrade process itself, thus removing any need of the nasty old static util classes.
For your upgrade process, you then have an @Reference to the XxxLocalService. It will be injected when the service is ready and then your upgrade process will be ready and everything will happen in a smooth sequence...
But wait, you'll say, the upgrade processes are not components and therefore cannot have @Reference injections. This is totally true, but the upgrade processes are added by the upgrade registrator which is, in fact, a component that can have @Reference injections.
So the registrator needs to have all of the @Reference values for all of your upgrade processes, then it can pass them in while creating the upgrade process itself, thus removing any need of the nasty old static util classes.
Thank you David for the answer. Need to check that it works properly.
After verification, it works properly. Thank you.
Yeah, unfortunately I don't think we got the messaging around the static utils usage right at all. Leads to all kinds of issues like the one that you found, Eric, that is often easily fixed by just ditching them in lieu of regular OSGi dependency injection...
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™