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

Friday, October 20, 2017

Annotation are the replacement for traditional
XML configuration in the application development. Usually any application we
can see many xml configurations, which will have set of predefined tags. Server
containers or other application execution engines will use these XML configurations.
Example Spring Web Applications, we have many spring configuration files, which
will be used by Spring Containers to make the Dependency Injection among the
beans. Similarly, Liferay have many xml
configuration files while developing portlets. To manage the many XML files in the project is
little tedious so experts come up with Annotations
so that we can avoid most of the XML configurations while developing
applications.

OSGi
Declarative Services (DS) uses the XML
configurations to manage component dependency injection in the OSGi
Environment. To avoid old XML configuration, we have OSGi Declarative Services Annotations. Usage of annotation are very
simple and simply define in the java classes wherever it requires. All Annotation configurations finally turn
into XML configuration and this kind of action will be taking care by the
annotation implementation libraries. Developer do not need to worry about that
part.

OSGi Declarative Service (DS) have
following are the important annotations to develop OSGi components.

@Component

@Reference

@Activate

@Deactivate

@Modified

Note:

All components are available in “org.osgi.service.component.annotations”
package.

@Component

@Component is very
important annotation in Declarative Services and it will make any simple java
class into OSGi component. Its class level annotation so the java class turn
into OSGi component.

Usually
the component have service implementation so we will use @Component annotation to make the services implementation java
class as Component to deliver services.

We can use @Component to any simple Java class in the OSGi component
development and all the components need not to have service implementation. We
can use @Component for any java
class in the OSGi bundle development.

When we declare java class as component
then the component registered in the Service Component Runtime registry so that
the component will be available to other component when it needed.

The @Component
have following attributes and all the attributes enclosed by braces. Each
attributes separated by comma.

The
following are the important attributes

name

immediate

service

property

Name:

Name uses to define the Component name.
Usually its fully qualified class name. This name will be uses as the reference
point for the other component.

Service
attribute is java service interface. Which tells that, for which service interface
the component is proving the implementation.

Property

If
component, needed any other configuration information we will provided as properties
and this will take list of key value pair values.

Note:

All the attributes are optional. As we
know, each component not necessary to provide the service implementation. Some
of them are service components and some of them are simple component, which
does not have any service implementation.

Case:
1

Simple
Component

When we use @Component it will turn into
as OSGi component.

Example
Component Java Class with @Component

package com.ls.ds.component;

import org.osgi.service.component.annotations.Component;

@Component

publicclass HelloComponent {

public HelloComponent() {

System.out.println("Hey
I am Simple OSGi Component");

}

}

Case:
2

Service
Component

As we know that usually component will
provide implementation for the services. Assume we have service interface and
have implementation class. Now we can make services implementation as component
with @Component annotation.

Example:

HelloService.java

package com.ls.ds.lsserviceprovider.services;

publicinterface HelloService {

public String greetHello();

}

HelloServiceImpl
Service Component

We will use @Component to service implementation class so that java class
became service component and these services will be available to other
components when it needed.

Target attribute will used to filter the
reference components. Sometime we may have multiple implementation for service.
It means we have many Service Components with different implementation. To identify
the right Component instance, we will use target attribute. Usually we use set
of properties for Component declaration so same properties will be used
@Reference target to filter the reference components.

unbind

Unbind is used to declare setter method
when the component is unbind or dissociated with the component. When the
attribute with “-” it means there is
no setter method is called after component unbind.