Apache Gogo Shell Commands Description

lb

Display list of bundles installed in OSGi module framework

lb | grep <BUNDLE_MATCH_PATTERN>

List of bundles with filter using grep command and you can pass any string or valid regex pattern.

bundle <BUNDLE_ID>

Print specific bundle information. It required bundle Id as parameter

headers <BUNDLE_ID>

Print all OSGi headers which is used by specified bundle. These headers are in MANIFEST.MF file. It is required bundle Id as parameter.

install [URI_JAR_FILE_PATH]

Install bundle into OSGi container and we need to specify the valid URI path.

start [BUNDLE_ID]

Command will start bundle and it is required bundle Id.

stop [BUNDLE_ID]

Command will stop bundle and it is required bundle Id.

uninstall [BUNDLE_ID]

Uninstall bundle and it required bundle Id.

inspect requirement service [BUNDLE_ID]

List all services required by bundle. Require-Capability header is in MANIFEST.MF file is relevant to this command.

inspect capability service [BUNDLE_ID]

List all services provided by bundle. Provide-Capability header is in MANIFEST.MF file is related to this command.

diag [BUNDLE_ID]

Command will print unsatisfied constraints to specific bundle and its required bundle Id.

upgrade:check

Command will display all Upgrade Step Process Steps registered in the registry.

system:check

Command will show all unsatisfied components list along with Gogo shell commands to troubleshoot in detail. It will run Declarative Service Soft Circular Dependency Checker, Declarative Service Unsatisfied Component Checker, Spring Extender Unavailable Component Checker

history

history will print all commands used in the current session. It is similar to Unix/Linux history command.

help

It will show all available commands and its description.

services

Command will print all registered service components available in the OSGi module framework.

services grep [SEARCH-PATTERN]

Command will print all registered service components available in the OSGi module framework with filter. It will narrow down the list.

ds:unsatisfied

Command will display all unsatisfied service component list in the OSGi module framework.

ds:unsatisfied [BUNDLE_ID]

Command will display unsatisfied service components to specified bundle. It’s required bundle Id

scr:info [COMPONENT_ID]

Command will print detailed information of given component. It required the component Id and we can get component Id when we use services/ ds:unsatisfied commands.

scr:list

It will display all components registered in service registry.

scr:list | grep [SEARCH-PATTERN]

It will display matching components registered in service registry.

dm

List all dependency manager components and these are mostly service builder service components from Liferay OSGi Module Framework.

dm OR grep [SEARCH-PATTERN]

List all matching dependency manager components and these are mostly service builder service components from Liferay OSGi Module Framework.

dm cp OR  dm compact

Display components in compact from.

dm nd OR dm nodeps

Command will display only components and it is hiding dependencies of the component.

dm na OR dm notavail

It will print only not available dependency components. It is very useful when we troubleshoot unsatisfied service builder components.

dm wtf

Detects where are the root failures for components. This is also most useful command to troubleshoot service builder components

Example Usage of Commands

lb lb | grep student bundle 1076 headers 1076 install "file:C://Liferay/Liferay7.2/student-web/target/student-web-1.0.0.jar" start 1076 stop 1076 uninstall 1076 inspect requirement service 1076 inspect capability service 1076 diag 1076 upgrade:check system:check history help services services | grep student ds:unsatisfied ds:unsatisfied 1075 scr:info 4884 scr:list scr:list | grep student dm dm | grep student dm cp dm nd dm na dm wtf

Author

Meera Prince

Liferay Contributor of the Year 2016
Liferay Top Contributor Award Winner 2015

Liferay Contributor of the Year 2014

Liferay Top Contributor Award Winner 2013

http://www.liferaysavvy.com 

Read More

Useful Apache Gogo Shell Commands in Liferay 7.2/DXP

Apache Gogo Shell is command line interface (CLI) to interact with OSGi module framework or OSGi container.

Apache Gogo shell is very useful in trouble shooting of module issues, getting module information and perform certain action like install, active and de-active OSGi bundles.

Liferay is already using Apache Gogo Shell and when we start Liferay 7.2/DXP portal, it will start automatically and we can use different ways to access Apache Gogo Shell in Liferay Portal Environment.

Access Felix Gogo Shell in Liferay 7.2/DXP Portal Environment

We can categorize Gogo shell commands in the following types.

Basic Commands

Declarative Services (DS) | Service Component Registry Commands (SCR) Commands

Dependency Management (DM) Commands

Basic Commands

Its regular usage commands to get bundles/module information like list bundles and its status.

Following are list of useful basic commands.

lb lb | grep <BUNDLE_MATCH_PATTERN> bundle <BUNDLE_ID> headers <BUNDLE_ID> install [URI_JAR_FILE_PATH] start [BUNDLE_ID] stop [BUNDLE_ID] uninstall [BUNDLE_ID] inspect requirement service [BUNDLE_ID] inspect capability service [BUNDLE_ID] diag [BUNDLE_ID] upgrade:check system:check history help

Example Usage

lb lb | grep student bundle 1076 headers 1076 install "file:C://Liferay/Liferay7.2/student-web/target/student-web-1.0.0.jar" start 1076 stop 1076 uninstall 1076 inspect requirement service 1076 inspect capability service 1076 diag 1076 upgrade:check system:check history help

Identify Bundle ID

Use lb command in the Gogo shell it will display the list of bundles installed in the OSGi modules framework. In the console view first column represent the BUNDLE ID.

Example

Declarative Services (DS) | Service Component Registry Commands (SCR)

Liferay module framework uses the OSGi Declarative Services/Service Component Registry to manage module components and its services references. Gogo shell leverage the Service Component Registry and Declarative Services. We can access services information using Gogo shell commands. 

In Liferay 7.2/DXP most of modules are using DS/SCR framework. Only service builder components are using the Apache Felix Dependency Management Framework to register and manage service components.

If you see any @Component or @Reference annotations in the java class, it implies that module components are using the Declarative Services/Service Component Registry Framework.

The following are some of useful Gogo Shell commands to insect components and its references.

services services grep [SEARCH-PATTERN] ds:unsatisfied ds:unsatisfied [BUNDLE_ID] scr:info [COMPONENT_ID] scr:list scr:list | grep [SEARCH-PATTERN]

Example Usage

services services | grep student ds:unsatisfied ds:unsatisfied 1075 scr:info 4884 scr:list scr:list | grep student

Identify COMPONENT ID

Use services/ ds:unsatisfied go shell commands and it will display component information and its ID.

Example 1

Example 2

Dependency Management (DM) Commands

Liferay Service Builder is using Apache Felix Dependency Management framework to manage components and its dependencies. Apache Gogo Shell leverage the Dependency Management framework and have set of predefined commands to provide more details of service components.

These commands are very useful when we trouble shoot about unsatisfied services in the registry.

The following are some of useful Gogo Shell commands related to Dependency Management

dm dm | grep [SEARCH-PATTERN] dm cp dm nd dm na dm wtf OR dm dm | grep [SEARCH-PATTERN] dm compact dm nodeps dm notavail dm wtf

Example Usage

dm dm | grep student dm cp dm nd dm na dm wtf

Example usage screen

Reference

https://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager/tutorials/leveraging-the-shell.html

https://felix.apache.org/documentation/subprojects/apache-felix-gogo.html

http://www.liferaysavvy.com/p/liferay-7-tutorial.html

Author

Meera Prince

Liferay Contributor of the Year 2016
Liferay Top Contributor Award Winner 2015

Liferay Contributor of the Year 2014

Liferay Top Contributor Award Winner 2013

http://www.liferaysavvy.com 

Read More

OSGi Dependency Management

OSGi is defining dynamic component development for JAVA. Complex application divided into multiple modules. These modules can communicate each other.  OSGi dependency management provide way to manage their dependencies among each other.

When we break the application into multiple bundles none of the classes or interfaces not available to other bundles until we do some configuration in the bundles. Dependency management define the way to share these classes between the bundles.

Before expose these classes or uses it in other bundles we have to define this information in the OSGi MANIFEST file with some specific headers.

We have mechanism called Export and Import in the OSGi and such way we can export one-bundle classes and we can use these exported classes in other bundle by using import mechanism.

We have following headers, which define the package level dependency in OSGi bundles and these headers need to define in the MENIFEST file.

Export-Package:  

We have to specify the package names with comma separated values, which we wanted to export such way it can be available to other bundles.

Example:

Export-Package: com.liferaysavvy.example.service, com.liferaysavvy.example.service1

 Import-Package:

Import package will use to user other bundle classes that already exported by the other bundles.

Example:

Export-Package: com.liferaysavvy.example.service, org.osgi.framework; version="1.3.0"

 OSGi have several other ways to manage their decencies between bundles. Such a way other classes are visible to the bundles.

The following are different ways.

Boot Classpath

It will define the basic classes and jar file required by the bundles or OSGi container. Example java.* package classes are available in the boot classpath level.

Framework Classpath

Its separate class loader and OSGi framework related classes and packages are available. Specially OSGi framework API and its implementation classes.

Bundle space

Bundle space consist of JAR file, which used by the bundle like dependency jar files, which are used current bundle only.

Imported packages

Imported packages will consist of specific classes imported by the bundles. Let us say bundles have many components but some of components wants to make visible to other bundles and these specific classes are available in Imported packages

In this case, we will use Import-Package header, which will make set of classes visible to other bundles.

There are many headers, which we can define in the OSGi bundle MENIFEST file. The following are the important headers, which are involved in the dependency management.

Export-Package:  

We have to specify the package names with comma separated values, which we wanted to export such way it can be available to other bundles.

Import-Package:

Import package will use to user other bundle classes that already exported by the other bundles.

Bundle-Classpath:

Bundle-ClassPath define list of comma separated jar files or directories which will used by the current bundle.

Export-Service

Export-Service Define specific services that make visible to other bundles.

Import-Service

What are the services exported by bundles can be used by other with Import-Service header.

There are other headers and each header have its own importance in the OSGi MANIFEST file. Get all header information from the following link

https://www.osgi.org/bundle-headers-reference/

http://bnd.bndtools.org/chapters/800-headers.html

When we work with dependency management following are the steps. Usually we have at least two bundles to make work dependency management.

Bundle A

Define your services in the interface

Implement services for the defined interfaces

Add your services package path under Export-Package header in MANIFEST file

Register your Service implementation Object in “Bundle A” Activator class

Bundle B

Define exported package name under Import-Package header in MANIFEST file.

Get Service Object in “Bundle B” Activator class

Service Trackers:

Sometime one interface have multiple implementations and bundles export the same interface package, and each bundle register different Implementation Object in the Bundle Context with same interface class name.  Service Tracker is the way to filter the implantation by specific properties such a way consumer bundle can get right implementation service. 

Author

Meera Prince

Liferay Contributor of the Year 2016
Liferay Top Contributor Award Winner 2015

Liferay Contributor of the Year 2014

Liferay Top Contributor Award Winner 2013

http://www.liferaysavvy.com 

Read More