Liferay Development

Liferay Consulting

Liferay Training

Your Trusted Liferay Solutions Partner

Monday, February 24, 2020

Access Felix Gogo Shell in Liferay 7.2/DXP Portal Environment


Apache Felix Gogo shell is command line interface (CLI) to interact with Liferay Module Framework or OSGi container.

It will provide set of predefined commands to access bundle or modules information like list bundles installed in OSGi container, Services Registry Information and Dependency Management related details.

We have many ways to access the Apache Felix Gogo shell
  • Command Prompt in Windows
  • Putty Terminal
  • Liferay Blade CLI
  • From Liferay Portal Control Panel

Command Prompt in Windows

Make sure portal server should start before start using Apache Gogo shell
Command Prompt in Windows.

Open command prompt in windows and using following telenet command.

telnet localhost 11311

Use simple command lb it will list the bundles installed in the OSGi container.


Gogo shell using 11311 is default port number configured by Liferay Portal and we can change the port number as well.

Use disconnect to end the session.


Note:

Should not use shutdown, close, and exit commands in the Gogo shell and it will lead to showdown OSGi framework.

If you see “Telnet is not recognized as an internal or external command” enable Telenet in windows. Follow below link


Putty Terminal

We can also use putty terminal to connect to Gogo shell. If you don’t have putty, download portable putty from following link for windows and extract in local machine.


Click on putty executable and it will launch putty new session window.


Provide following details and open session and it will launch Gogo shell terminal.

Host Name: localhost
Port: 11311
Connection Type: telenet





Use help command to know about available commands.


Note:

We can also connect to remote host and need to provide valid remote host name or ip address.

Liferay Blade CLI

If Liferay Blade CLI already install simple use following command.

blade sh <gogo-shell-command>

Example


blade sh lb
blade sh help



If BLADE not installed follow below link.


From Liferay Control Panel

We can use Liferay Portal Control Panel to access Gogo shell. Login as Portal Admin and portal configuration, we can find Gogo shell app

Login As Portal Admin à Control Panel à Configuration à Click on Gogo Shell


Enter valid Gogo shell command as input and click on execute.


Author

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

Recent Posts

Recent Posts Widget

Popular Posts