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 the database, all tables for service
builder portlets are 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
at org.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 true
and 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.upgrade
should 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. ServeletContextName
should your service bundle symbolic name.
Step:3
Update service bundle bnd.bnd Liferay-Require-SchemaVersion
to 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.api
instead 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)
public class MyCustomModuleUpgrade implements UpgradeStepRegistrator {
@Override
public void 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 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
Posts
