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

Apache Blueprint Introduction

Apache Blueprint is container specification, which defines the dependency injection for OSGi. It is a dependency injection framework for OSGi bundle development.

Liferay 7/DXP came up with OSGi support. We can use Apache Blueprint framework to develop Liferay Application OSGi bundles. We can use either OSGi Declarative Services (DS) or Apache Blueprint to develop Liferay bundles. This article gives basic idea of Apache Blueprint framework.

We already know Declarative Services in OSGi. Apache Blueprint is similar to DS. Blueprint is enable component services make it available and unavailable at any point of time. Apache Blueprint based on OSGi Compendium R4.2 specifications.

Apache Blueprint is container specification based on OSGi extender pattern. Extender pattern is very used pattern in OSGi environment to extend semantics of bundle by adding new MANIFEST headers. To add addition features to existing bundle nature, we will use OSGi extender pattern. Best example is OSGi Declarative Services. OSGi Declarative Services used extender pattern so that it will provide dynamic nature to the components and it services.

Apache Blueprint is used extender pattern as well.  Apache Blue print extender bundles monitor the bundles state in the framework and perform the action on behalf of the bundle based on their actual state.

Extender bundle is responsible to identify the bundle is blueprint bundle or not, once the bundle activated the OSGi container. Extender bundle will look for the Blueprint xml files in the bundle. If any bundle have Blueprint xml files then it will treat bundle as blue print framework bundle. Usually blueprint xml files located in the fixed location in the place OSGI-INF/blueprint/ directory or are specified explicitly in the Bundle-Blueprint manifest header.

Once bundle is blueprint bundle, then it will create the Blueprint container for the bundle and it is responsible for following actions. These actions are similar to Spring Framework Dependency Injection. If we are familiar with Spring framework then it will be easy to understand OSGi dependency Injection through Blueprint framework.

XML file parsing

Instantiate the components

Wiring the component together

Registering the services

Looking up service references

Blueprint XML Configuration

Blueprint framework uses the XML configurations to declare beans and its wiring. Blueprint container read this xml configuration file to instantiate and wiring the beans. Blueprint is top-level xml tag.

The following is basic declaration which specify the blueprint configuration

<?xml version="1.0" encoding="UTF-8"?> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"> ... </blueprint>

The XML namespace identifies the document as conforming to the Blueprint version 1.0.0. The top-level blueprint element identifies the document as a blueprint module definition.

Bean Declaration

Blueprint uses the bean tag to declare beans. Bean tag have id attribute, which is unique identification for bean.

The following is example of bean declaration.

<?xml version="1.0" encoding="UTF-8"?> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"> <bean id="helloServiceOne" class="com.liferaysavvy.blueprint.HelloService" /> </blueprint>

Bean Constriction

Blueprint container will look for right constrictor to instantiate the beans. This information provided as bean attributes or its child tags. Instantiation can be happen with the constrictor or factory method. By default, the Blueprint Container uses the number and order of the argument elements in XML to find the right constructor or method.

To help the Blueprint Container pick the right constructor, method, or parameter arrangement, additional attributes, such as index or type, can be specified on the argument element. For example, the type attribute specifies a class name used to match the argument element to a parameter by the exact type.

Beans instantiation with constructor

The following example for bean instantiation with constructor

Java Class

public class HelloService {     public HelloService(long number) {     } }

Blueprint XML configuration

<bean id=" helloServiceOne" class="com.liferaysavvy.blueprint.HelloService"> <argument value="1"/> </bean>

Beans instantiation with factory method.

Bean construction can be happen through the static factory method as well. We will use bean factory-method attribute so that Blueprint container identify it and it will instantiate bean by using factory method.

The following is example for Beans instantiation with factory method.

Java Class

public class StaticHelloServiceFactory {     public static HelloService createHelloService(long number) {         return new HelloService(number);     } }

Blueprint XML configuration

<bean id="helloServiceTwo" class="com.liferaysavvy.blueprint.StaticHelloServiceFactory" factory-method="createHelloService"> <argument value="2"/> </bean>

Bean Properties

Blueprint have property tag to provide additional configuration to the bean and the container will use it whenever bean required.

The following is example to access and declare the properties for the beans.

Java class

public class HelloService {     public HelloService(long number) {     }     public String getMessage() {     } }

Blueprint XML configuration

<bean id="helloServiceOne" class="com.liferaysavvy.blueprint.HelloService"> <argument value="1"/> <property name="message" value="Hi I am Hello Service"/> </bean>

Bean Wiring

Sometimes one bean dependence on other bean. We should wire the bean into the current bean. Property injection is used for wiring beans together. In the following example, helloServiceOne is injected with a DependencyService bean.

Java Classes

public class HelloService {     public HelloService() {     }     public void setDependencyService (Currency currency) {     } } public class DependencyService  {     public DependencyService () {     } }

Blueprint XML configuration

<bean id="helloServiceOne" class="com.liferaysavvy.blueprint.HelloService"> <property name="dependencyService" ref="dependencyService" /> </bean> <bean id="dependencyService" class="com.liferaysavvy.blueprint.DependencyService" />

Services

Blueprint framework provide the configuration to register service in OSGi service registry. Blueprint xml have service tag it will register the declared services. Service implementation will be referred through ref attribute.

Service Interface

Service Interface container set of services and its simple java interface.

public interface HelloService {     public String sayHello(); }

Service Implementation

Service implementation provided the implementation to the service interface.

public class HelloServiceImpl implements HelloService {     public HelloServiceImpl () {     }     public void sayHello() {     } }

Blueprint XML configuration

<service id="helloServiceOne" ref="helloServiceImpl" interface="com.liferaysavvy.blueprint.api.HelloService"/> <bean id="helloServiceImpl" class="com.liferaysavvy.blueprint.impl.HelloServiceImpl"/>

Without using ref attribute we can also declared service implementation as inline to the service declaration

<service id="helloServiceTwo"  interface="com.liferaysavvy.blueprint.api.HelloService"> <bean class="com.liferaysavvy.blueprint.impl.HelloServiceImpl" /> </service>

The interfaces under which a service is registered can be determined by Blueprint using auto-export. The following registers the service under all the bean's interfaces

<service id="helloServiceOne" ref="helloServiceImpl" auto-export="interfaces" /> <bean id="helloServiceImpl" class="com.liferaysavvy.blueprint.impl.HelloServiceImpl"/>

Note:

Other values for auto-export are disabled (the default) class-hierarchy and all-classes.

Service Properties

We also configure requires properties for the service using service-properties tag. This service-properties tag contains multiple entry tags to declared properties and it has key and type as attributes. The service property values can be of different types, but only OSGi service property types are permitted: primitives, primitive wrapper classes, collections, or arrays of primitive types.

The following is example for property declaration

<service id="helloService" ref="helloServiceImpl" autoExport="all-classes"> <service-properties>     <entry key="active">         <value type="java.lang.Boolean">true</value>     </entry>     <entry key="message" value="say hi"/> </service-properties> </service>

Service Ranking

When one service have multiple implementation then service ranking used to choose the matching service implementation. The default ranking value is 0. Service ranking is specified using the ranking attributes as follows:

<service id="serviceFive" ref="account" auto-export="all-classes"   ranking="3" />

Service Reference

Services are found in the OSGi service registry using the reference element from the Blueprint xml file. The following configuration reference tag referencing the HelloService. If this service found in the OSGi registry then it will be set in the HelloServiceClient.

Blueprint Service Reference XML configuration

<bean id="helloworldClient" class="com.liferaysavvy.blueprint.client.HelloServiceClient"> <property name="helloService" ref="helloServiceRef" /> </bean> <reference id="helloServiceRef" interface="com.liferaysavvy.blueprint.api.HelloService"/>

Blueprint Implementation Example

Usually OSGi service implementation have their basic bundles. Service API, Service API Provider and Service Client.

Follow below articles

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

http://www.liferaysavvy.com/2017/09/osgi-bundle-manifest-headers.html

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

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

Service API

Service API consist set of services. It means simple interfaces and its abstract methods. These we will make it as bundle. Usually we use export mechanism to make these interfaces available to other bundles.

Hello Service Interface

public interface HelloService {     public String sayHello(); }

Service API Provider

Service Provider bundle usually implement the services defined in the Service API bundle.

Hello Service Implementation

public class HelloServiceImpl implements HelloService {     public String sayHello(){     } }

XML configuration

<?xml version="1.0" encoding="UTF-8"?> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"> <service id="helloServiceOne" ref="helloServiceImpl" interface="com.liferaysavvy.blueprint.api.HelloService"/> <bean id="helloServiceImpl" class="com.liferaysavvy.blueprint.impl.HelloServiceImpl"/> </blueprint>

Service Client

Service Client is other bundle, which use the services provided by Service Provider bundles.

public class HelloServiceClient {     HelloService helloService = null;     public HelloService getHelloService() {         return helloService     }     public HelloService setHelloService(HelloService helloService) {         this.helloService = helloService;     } }

XML configuration

<?xml version="1.0" encoding="UTF-8"?> <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"> <bean id="helloworldClient" class="com.liferaysavvy.blueprint.client.HelloServiceClient"> <property name="helloService" ref="helloServiceRef" /> </bean> <reference id="helloServiceRef" interface="com.liferaysavvy.blueprint.api.HelloService"/> </blueprint>

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