Differences between Liferay Module and Liferay Plugin

The objective of this article is providing the major differences between Liferay Module and Liferay Plugin.

Before understand difference we must have basic idea of OSGi and Liferay 7 Fundamentals.

Follow Liferay DXP/7 Tutorial to get more information.

Liferay 7 / DXP Tutorial

Liferay Modules	Liferay Plugins
Introduced in Liferay 7	Introduced since Liferay Started. From Liferay 4.x to Liferay 7/DXP
Liferay Modules are based on OSGi framework	Liferay Plugins based traditional Java web application framework. Like we use more J2EE web application Frameworks.
Liferay Module will run in OSGi Run Time Environment.	Liferay Plugins run in Traditional Application Servers such as Tomcat, JBoss , Glassfish
Liferay Module we can call it as OSGi bundles and packaged as JAR file.	Liferay Plugins are web applications and packaged as WAR files.
Liferay Module provides the dynamic component injection with help OSGi so that we can make most of the features as independent components and can easily inject into the other components when it required.	Liferay plugins are like independent web applications we cannot share anything between two web applications. It is more coupled. If we want share some classes we have to put these jar files in some global class loaders then only other web application can use that classes.
We can avoid all the problems of class loader issues.	We can see more class loader issues.
No Class Definition Found, Class Not Found Run time errors completely vanished in the runtime.	We frequently experience No Class Definition Found, Class Not Found Run time errors in the runtime.
Liferay Modules have different types like Portlet Modules, Hook Modules. Themes and Layouts partially support modularity.	Liferay plugins have different types such as portlets, themes, ext, layout and hooks.
Liferay Modules developed based on OSGi Framework and it used the several framework to develop modules such as Declarative Services (DS), Apache Blueprint and OSGi API.	Liferay Plugins uses the J2EE web application frameworks such as Struts, Spring, Liferay MVC, JSF and other web application frameworks.
Liferay Modules followed 3-tier architecture application development such as Persistence, Service and Presentation layered architecture.	Liferay Plugins uses the same 3-tier architecture application development such as Persistence, Service and Presentation layers architecture.
Usually Liferay Module development we separated each Layer as Independent Modules Persistence Tier Module Service Tier Module Web Tier Module	Liferay Plugins Development all 3 tiers packaged as single WAR file.
Liferay Modules support the dynamic deployment feature and we can stop and start module without un-deploy the module.	Liferay Plugins we must un-deploy the war file from server to remove features.
Liferay Modules uses the Apache Gogo shell Command Line Interface (CLI) to manage the Liferay Modules in the OSGi run time environment. Like stop, start, activate and deactivate. Liferay Portal Admin screen also have to manage these Liferay modules.	Liferay plugins does not have any Command Line Interface to un-deploy the bundles and we have to removed plugin war files from servers. Some Enterprise Application Servers have administrative feature to do these things. Liferay Portal Admin screen also have option to manage these Liferay plugins.
Liferay modules are available in Liferay Portal Server Bundle inside OSGI directory once the module is deployed.	All Liferay Plugins are available in Liferay Portal Server webapps directory.
Liferay Module have important configuration file METAINF which is like module deployment configuration file have more information used by OSGi run time environment.	Liferay Plugins have web.xml file and used by Portlet/Servlet containers.
Liferay portlet module all xml configuration files information turn into Declarative Services (DS) Component properties. Like portlet.xml, liferay-portlet.xml and liferay-display.xml files tags and values.	Liferay Plugins used the XML configuration such as portlet.xml, liferay-portlet.xml and liferay-display.xml
If the Liferay Application have more features then we divided into multiple independent modules and these modules can communicate each other very easy in OSGi environment.	Modularity is not that easy in Liferay Plugins development so we have to keep all the files in single WAR file.
Liferay Module introduced new tool called BLADE CLI to develop Liferay Modules.	Liferay Plugins have Plugins SDK to develop Liferay Applications.
Liferay Modules have several tools such as Liferay IDE, Liferay Studio, BLADE CLI	Liferay Plugins have tools such as Liferay IDE, Liferay Studio.
Liferay Module support GRADLE and MAVEN build environment.	Liferay Plugins support ANT and MAVEN build environment.
Liferay Modules used the Liferay Workspace concept to manage the application and its configuration across the platforms.	Liferay Plugins uses the Plugins SDK to develop and manage the plugins.
Liferay Modules used the OSGi API, Declarative Services and Apache Blueprint framework. So we have limited choice to use popular we application framework like Spring. Liferay still not fully supporting Spring Modules, it means we have to use the WAR deployment.	We can use any J2EE popular web application frameworks such as Spring, Struts and JSF.
Liferay Modules provides the Micro services Architecture based applications.	To bring Micro services Architecture we have to depend on other frameworks such as Spring Micro Services.
Liferay Modules have dynamic component development feature so we can easily turn on and off the feature at any point of time with minimal effort.	Liferay Plugins not like Dynamic Component Development so bunch of feature in one plugin application. If we remove one plugin, it can turn off many features.
Liferay Modules can provide easy way deployment process and we can move easily from one environment to other with minimal effort. Liferay Workspace provided this capability.	Liferay Plugin Deployment process and moving from one environment to other tedious. We do not have any special mechanism like Liferay Workspace.
Liferay Modules uses the Bndtools to develop and build the modules. We have BLADE CLI, Liferay IDE, GRADLE and MAVEN are used the Bndtools internally.	Liferay Plugins follow the J2EE web application development so MAVEN Liferay Plugin or Liferay IDE handle the Development and Deployment.

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 Declarative Services Detailed Information

OSGI Declarative Services is a mechanism to create components and manage dependencies among the components. DS we can also called Service Component Runtime and DS and SCR convey same thing in the OSGi Development.

DS will use the XML configuration to define components and its references.  XML files available in the OSGi bundle. When we are talking about DS/SCR, we have following terminology such as Component, Services and Lifecycle.

The following article will gives idea of OSGI Declarative Services.

http://www.liferaysavvy.com/2017/09/osgi-declarative-services-ds.html

Components

OSGi primary artifact is Components. Declarative Services created the Component and managed by the OSGi Service Component Runtime.

The following terminology required when we are talking about OSGi components.

Service Component

Service Component is java class declared by Component Description and managed by OSGi Component Service Runtime. This configuration is defined in the XML file with in the bundle.

Usually Service Components are providing set of services and these services perform certain tasks. These components services will be used in the other bundles.

We can declare every java class as OSGi components and not every component have services.  Sometimes component may not provide any service.

Once we declared java class as Service Component then services available to all the bundles, which deployed in the OSGi container.

Component Description

Component Description is XML configuration to Declare Service Component in the bundle. Usually this configuration is available in XML file in the bundle.

Component Configuration

Component Configuration consist of set of properties and it will be used to track the dependencies and manage the Component instance.

Component Instance

The instance of the component implementation class. It is created when a Component Configuration is activated and discarded if the Component Configuration is deactivated.

Note:

Usually XML configuration file should be available in OSGI-INF folder in the bundle.

We have to use following header in the bundle MANIFEST file to identify the XML file by OSGi SCR

Service-Component: OSGI-INF/com.liferaysavvy.example.HelloComponent.xml

Service References

Service reference manage the dependencies among the components. Usually OSGi Application development composed of one or more components. Most of the time there will be dependencies between components, it means one component services will be used in other component. Services Reference is the way to identity the other components services and consume in the dependency components.

Usually when we declare components then the service available to all other bundles and it will be automatically managed by Service Component Runtime.

Service reference will help us to identify the exact services in dependency bundles by using some filers and properties.

When we talking about Service Reference we have following terminology comes into picture

Reference:

Reference is definition of dependency to other service. It is key point which explain the component service depends on other component service.

Target Services

Target services is used to identify the exact reference implementation for the given interface configured in the configuration. Target reference will use some properties to filter service and find exact match.

Usually one interface have multiple implementations so to find required implementation from multiple implementation we will use target services to identify and hook the exact match.

 Bound Services

The services that are bound to a Component Configuration. The binding is done on activating a Component Configuration.

Component Lifecycle

We have different types of components available. The following are deferent component types

Delayed Components

Delayed component will not activated until its get first request to service from other component. This we will defined in the component description based on configuration component will ready and services are available to other components.

Immediate Components

Immediate Components will be ready as soon as deployed in the OSGi container. These services immediately available to other components.

Factory Component

Creates and activates new Component Configurations on request. The created Component Configurations are not re-used if they become unsatisfied or unregistered.

The following Lifecycle state possible for each component

ENABLED/DISABLED

Component initial enable state manage by component description. These component state controlled dynamically by using Component Context.

UNSATISFIED

Component will be unsatisfied if the dependency services not resolved. Sometimes dependency services might not be ready component will be in unsatisfied state.

SATISFIED

If component resolved by all dependency services then it will be in satisfied state and it will be ready to use.

RIGISTERED

If the component is satisfied then it will be registered in SCR and these services can be used in other components once it registered.

ACTIVE

Component activation dependent on its type. If the component is declared as immediate component in the component description then services will be in active state. If it is delayed component then it will be get ready once it gets first request to the service object.

Immediate Component Lifecycle

When we deployed the bundle it will be loaded into OSGi container and the bundle is in active state.

Based on Component description Component will be enabled and we already know its immediate component.

If the component reference not resolved then it will goes to UNSATISFIED state.

If the all reference services resolved then it will go to active state then component will be activated.

If any case other references not resolved then it will goes to unsatisfied state and component will be deactivated.

If the bundle is stopped then component will be disabled.

Delayed Components

Delayed component is little different then immediate component.

As soon as bundle started, Based on component description bundle goes to enabled state.

Once all the dependencies resolved then the component will registered with SCR

When the component get first request then component will be in Active state. Usually we will use getService/bind method to get service.

Once it’s in Active state then component will be activated and available to use.

If any case dependences not resolved then it will goes to Deactivate state finally it will be unregistered.

When will call unGetService/Unbind method then Component will goes to registered state. It means component ready to use, when it get requested.

Before Going through implementation please go through following articles to understand develop basic bundles with OSGi framework.

http://www.liferaysavvy.com/2017/08/osgi-sample-bundle-development-with.html

http://www.liferaysavvy.com/2017/09/osgi-dependency-management-example.html

Example Implementation

Step: 1

Service API Bundle

Usually Service API bundle have service interfaces. We need to declare all services in the interface. Once we declared all services then we need to export package to make available to other bundles.

HelloService.java

package com.ls.ds.lsserviceprovider.services; public interface HelloService {       public String greetHello(); }

Export Services Package

Now we have to Export Services package from services bundles so that these interfaces or resources can be accessible in the other bundles. Remember here only we are exporting services package not implementation package.

MANIFEST have OSGi header called “Export-Package” and we need to add package names with comma separate value, so that we can access these resources in other bundles.

Add “com.ls.ds.lsserviceprovider.services” package name under “Export-Package” in the 

Bundle MANIFEST file

Finally, MANIFEST looks as follows

MANIFEST.MF

Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: LSServiceProvider Bundle-SymbolicName: com.ls.de.LSServiceProvider Bundle-Version: 1.0.0.qualifier Bundle-Activator: com.ls.de.lsserviceprovider.ServiceActivator Bundle-Vendor: LS Bundle-RequiredExecutionEnvironment: JavaSE-1.8 Export-Package: com.ls.ds.lsserviceprovider.services Import-Package: org.osgi.framework;version="1.3.0"

Step: 2

Service Provider Bundle

We already have Service API bundle and the services exported. Now we have to implements the service method in the implementation class. Create new bundle and implement the services, which defined in Service API, bundle. Implement interface method in the implementation class, finally implementations class as follows.

HelloServiceImpl.java

package com.ls.ds.lsserviceprovider.services.impl; import com.ls.de.lsserviceprovider.services.HelloService; public class HelloServiceImpl implements HelloService {       @Override       public String greetHello() {                   System.out.println("=====Inside HelloServiceImpl.greetHello()=====");         return "Hello Greeting from Liferay Savvy World..";      } }

MANIFEST.MF

To use Service API bundle service interfaces in the Provider bundle we need to import the package in the MANIFEST file with Import-Package Header.

Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: LSServiceProviderImpl Bundle-SymbolicName: com.ls.de.LSServiceProviderImpl Bundle-Version: 1.0.0.qualifier Bundle-Vendor: LS Bundle-RequiredExecutionEnvironment: JavaSE-1.8 Import-Package: com.ls.ds.lsserviceprovider.services,  org.osgi.framework;version="1.3.0" Service-Component:OSGI-INF/com.ls.ds.lsserviceproviderimpl.servicescomponent.xml

Component Declaration

We have to declare component description in services component XML file, which is in bundle OSGI-INF folder. Name can be anything in this case its “com.ls.ds.lsserviceproviderimpl.servicescomponent.xml”

The following is component declaration in the xml file

<?xml version="1.0" encoding="UTF-8"?> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"      name="com.ls.ds.lsserviceprovider.services.impl.HelloServiceImpl">      <implementation           class="com.ls.ds.lsserviceprovider.services.impl.HelloServiceImpl" />      <property name="service.description" value="Sample Hello Service" />      <property name="service.vendor" value="Liferay Savvy" />      <service>            <provide interface="com.ls.ds.lsserviceprovider.services.HelloService" />      </service> </scr:component>

Note:

We have many XML tags, which we can find in the SCR XML DTD file.

https://osgi.org/xmlns/scr/v1.1.0/scr.xsd

Step: 3

Service Consumer Bundle

Usually in the Service Consumer bundle, we will use component services, which implemented in the other bundles. In this case, we will use services, which are developed in the Service Provider Bundle. We have to use bind method setXXX() type . If we observed in the below implementation we are using service greetHello that was implemented in other bundle. This is how we can reference one-bundle services in other bundles.

ConsumerComponent.java

package com.ls.ds.consumer.component; import com.ls.ds.lsserviceprovider.services.HelloService; public class ConsumerComponent {           public void activate() {                      System.out.println("=====Consumer Component Active=====");      }       public void setHelloService(HelloService helloService) {            System.out.println("=====Inside Consumer Component setService()=====");            System.out.println(helloService.greetHello());          } }

MANIFEST.MF

To use Service API bundle service interfaces in the Provider bundle we need to import the package in the MANIFEST file with Import-Package Header.

Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: LSServiceConsumer Bundle-SymbolicName: com.ls.ds.ConsumerComponent Bundle-Version: 1.0.0.qualifier Bundle-Vendor: LS Bundle-RequiredExecutionEnvironment: JavaSE-1.8 Import-Package: com.ls.de.lsserviceprovider.services,  org.osgi.framework;version="1.3.0" Service-Component:OSGI-INF/com.ls.ds.consumercomponent.xml

Component Declaration

We have to declare component description in services component XML file, which is in bundle OSGI-INF folder. Name can be anything in this case its “com.ls.ds.consumercomponent.xml” to consume other services in the component we have use reference tag. We have to specify the bind method name and service interface in the properties.

The following is component declaration in the xml file

<?xml version="1.0" encoding="UTF-8"?> <scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0"      name="com.ls.ds.ConsumerComponent">      <implementation class="com.ls.ds.ConsumerComponent" />      <property name="service.description" value="Sample Consumer Component" />      <property name="service.vendor" value="Liferay Savvy" />      <reference bind="setHelloService" cardinality="1..1"      interface="com.ls.ds.lsserviceprovider.services.HelloService" name="HelloService" policy="static" /> </scr:component>

Note:

We have many XML tags, which we can find in the SCR XML DTD file.

https://osgi.org/xmlns/scr/v1.1.0/scr.xsd

From the three steps, we can understand that how we can implement services and how we can referred into other bundles. This is how declarative services will help share service among bundles.

Important Note

We can implement Declarative Service with help of annotations. XML configuration will be replaced by annotations. So this article will explain how exactly happen when we use Declarative Services.

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