When we upgrade portal from older version to newer version, we can see following issues when we deploy migrated service builder bundles. Specially from Liferay 6.1/6.2 to Liferay 7.2/DXP.
Liferay 6.1/6.2 Release_ tables will not add any records for service builder services until unless if write Upgrade Step Process. Liferay 7.2/DXP will behave very different and each and every service builder service must be register in Release_ tables then only service will be available in service registry.
Release_ Table
When we upgraded database, all tables for service builder portlets already existed and when we try to deploy migrated bundles in Liferay 7.2 we can see following issues.
The following service(s) are missing: * com.liferay.portal.kernel.configuration.Configuration (&(configuration.bundle.symbolic.name=com.foo.mytest.service)(name=service)) is not found in the service registry * com.liferay.portal.kernel.model.Release (&(release.bundle.symbolic.name=com.foo.mytest.service)(&(release.schema.version>=1.0.0)(!(release.schema.version>=1.1.0)))(|(!(release.state=*))(release.state=0))) is not found in the service registry |
g! dm na [950] com.foo.mytest.service [89] com.liferay.portal.spring.extender.internal.configuration.ServiceConfigurationInitializer unregistered com.liferay.portal.kernel.model.Release (&(release.bundle.symbolic.name=com.foo.mytest.service)(&(release.schema.version>=1.0.0)(!(release.schema.version>=1.1.0)))(|(!(release.state=*))(release.state=0))) service required unavailable [90] com.liferay.portal.spring.extender.internal.context.ModuleApplicationContextRegistrator unregistered com.liferay.portal.kernel.model.Release (&(release.bundle.symbolic.name=com.foo.mytest.service)(&(release.schema.version>=1.0.0)(!(release.schema.version>=1.1.0)))(|(!(release.state=*))(release.state=0))) service required unavailable com.liferay.portal.kernel.configuration.Configuration (&(configuration.bundle.symbolic.name=com.foo.mytest.service)(name=service)) service required unavailable g! |
Caused by: org.postgresql.util.PSQLException: ERROR: relation "foo_foo" already exists atorg.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2412) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2125) |
We can use following Gogo shell commands to know more about above issues.
ds:unsatisfied scr:info <service-if> inspect cap service <bundle-id> dm wtf dm na dependencymanager:dm |
Background of Issue
Liferay 7.2 Service builder portlet will use Release_ table to manage versions and each and every service must register in the table for first deployment (Service Builder Bundles). This will help to run Upgrade Step process in future to update/add database related activities for non-developer mode environments. For migrated database tables already existed for each and every service builder so its assumed that bundle already deployed once and looking for Release_ table version to proceed and register service.
We can categorize these things into two types of environments
Developer Environment
Example:
Local Development environment for developers schema changes will reflect automatically through schema.module.build.auto.upgrade is trueand it will be run based on build number in the service.properties file.
Developer Environment Solution
We can resolve above two issues for Developer Environment with following options.
Option: 1
For local developments is very simple, delete service builder generated tables and delete record from Release_ table (If already exist) then redeploy service bundle then problem will be resolved.
Option: 2
This option will get rid of the manual deletion. We can use Liferay provided Maven or Gradle plugin called DB Support Plugin. Follow the reference links to know more about DB Support Plugin.
For Maven
Add DB Support plugin in the pom file and run db-support:clean-service-builder maven goal so that it will clean
For Gradle
Note:
Option: 1 and Option: 2 recommended for developer environment and your data will be lost in both cases. If you wanted avoid data lost follow the Non-Developer Environment solution.
Non-Developer Environment
Example: Production or Real Lower Level Environments DEV/SIT/UAT
For non-developer mode schema.module.build.auto.upgradeshould be false and we have to write Upgrade Step Process component class to update database schema changes. We can also use DBA to execute schema changes related service builder.
Non-Developer Environment Solution
Step:1
Delete bundle from portal osgi\modules directory if already deployed.
Step:2
Add release record in Release_ table with default version 1.0.0 for your service. ServeletContextNameshould your service bundle symbolic name.
Step:3
Update service bundle bnd.bnd Liferay-Require-SchemaVersionto default version that we already enter in the Release_ table record.
Step:4
Write dummy upgrade step in service. Follow the reference to create upgrade step with my notes.
You can skip “Writing upgrade steps and Waiting for upgrade completion” because we are trying to use the Dummy Upgrade Step that already as part of portal class loader.
Declaring dependencies need be corrected use com.liferay.portal.upgrade.apiinstead of com.liferay.portal.upgrade
Gradle:
Add following in the service build.gradle file
compile group: "com.liferay", name: "com.liferay.portal.upgrade.api", version: "2.0.0" |
Maven:
Add following in the service pom.xml
<dependency> <groupId>com.liferay</groupId> <artifactId>com.liferay.portal.upgrade.api</artifactId> <version>2.0.0</version> </dependency> |
Upgrade Step Registration
package com.liferaysavvy.student.upgrade; import com.liferay.portal.kernel.upgrade.DummyUpgradeStep; import com.liferay.portal.upgrade.registry.UpgradeStepRegistrator; import org.osgi.service.component.annotations.Component; @Component(immediate = true, service = UpgradeStepRegistrator.class) publicclass MyCustomModuleUpgrade implements UpgradeStepRegistrator { @Override publicvoid register(Registry registry) { registry.register( "1.0.0", "1.0.1",new DummyUpgradeStep()); } } |
Step:5
Restart Portal
Step:6
Build and deploy your service bundle. You can manually copy service jar to your OSGI module directory or use CI/CD to build and deploy service bundle to respective environments.
Step:7
You can verify the changes using above mentioned Gogo shell commands. Service should not be in the unsatisfied list. You can also can notice your upgrade step process (upgrade:check).
If still see issue you can delete osgi cache and repeat same steps one more time.
We can notice new version is updated in Release_ table for deployed service and it will be created by Dummy Upgrade Step Process.
Note:
If you plan for production portal database upgrade. Identify all modules that you are migrating as Service builder bundles, write SQL script to add records in Release_ table with default version and keep this step as part of post upgrade process.
References:
Author
