Monday, February 24, 2020

Liferay 7.2/DXP Service Builder Behavior for Upgraded Database

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 (&( is not found in the service registry
 * com.liferay.portal.kernel.model.Release (&(>=1.0.0)(!(release.schema.version>=1.1.0)))(|(!(release.state=*))(release.state=0))) is not found in the service registry

g! dm na
 [89] com.liferay.portal.spring.extender.internal.configuration.ServiceConfigurationInitializer unregistered
    com.liferay.portal.kernel.model.Release (&(>=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 (&(>=1.0.0)(!(release.schema.version>=1.1.0)))(|(!(release.state=*))(release.state=0))) service required unavailable
    com.liferay.portal.kernel.configuration.Configuration (&( service required unavailable

Caused by: org.postgresql.util.PSQLException: ERROR: relation "foo_foo" already exists
    at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(
    at org.postgresql.core.v3.QueryExecutorImpl.processResults(

We can use following Gogo shell commands to know more about above issues.

scr:info <service-if>
inspect cap service <bundle-id>

dm wtf
dm na

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


Local Development environment for developers schema changes will reflect automatically through is true and it will be run based on build number in the 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


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 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


Delete bundle from portal osgi\modules directory if already deployed.


Add release record in Release_ table with default version 1.0.0 for your service.  ServeletContextName should your service bundle symbolic name.


Update service bundle bnd.bnd Liferay-Require-SchemaVersion to default version that we already enter in the Release_ table record.


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


Add following in the service build.gradle file

compile group: "com.liferay", name: "com.liferay.portal.upgrade.api", version: "2.0.0"

Add following in the service pom.xml


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 {

    public void register(Registry registry) {
        registry.register( "1.0.0", "1.0.1",new DummyUpgradeStep());




Restart Portal


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.


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.

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.




  1. You may be amazed by how many home owners forget about their kitchens whilst selling their residence.המלצות בעלי מקצוע

  2. By the day's end, the arrangement was practically unavoidable, regardless of whether it had been Google, Apple or another organization inside the haze of combinations that could have purchased Github. visit website

  3. Really, amazing content.


Recent Posts

Recent Posts Widget

Popular Posts