23 November, 2016

Spring MVC Portlet Migration - DXP


Do you want to migrate your Spring MVC portlet into DXP ? yooo here are the steps you will have to follow to get it migrate.

Before we jump into steps, let me light up regarding spring mvc. Actually Spring MVC is purely used for web project architect and there is no any specific intention to get it convert into OSGi module jar. So here we may not be able to convert it into module jar but  such kind of portlets will get deployed as a war file only and Liferay container will convert into OSGi compatible WAB (Web Application Bundle) project by  Liferay WAB Generator.

Follow below steps to get it convert

22 November, 2016

Custom portlet configuration - DXP

Hello Folks,

Here I have tried to put all the possible steps which we would required to introduce custom portlet configuration.

1) Create new Liferay module using mvcportlet template
2) Define below highlighted property in your controller class:
        immediate = true,
        property = {

        service = Portlet.class
public class SamplePortletextends MVCPortlet {

3) Introduce custom interface for models with unique id as highlighted

            id = "com.sample.action.SamplePortletConfig "        )
        public interface SamplePortletConfig {
        deflt = "blue",
        required = false
    public String favoriteColor();

       deflt = "red|green|blue",
       required = false
    public String[] validLanguages();

    @Meta.AD(required = false)
    public int itemsPerPage();

Note :
  1. Meta.OCD: Registers this class as a configuration with a specific id. You can choose any string you want, but make sure it’s unique. A common pattern is to use the fully qualified class name.
  2. Meta.AD: Specifies the default value of a configuration field as well as whether it’s required or not. Note that if you set a field as required and don’t specify a default value, the system administrator must specify a value in order for your application to work properly. Use the deflt property to specify a default value.

4) Create custom config action class

        configurationPid = "com.sample.action.SamplePortletConfig",
        configurationPolicy = ConfigurationPolicy.OPTIONAL, immediate = true,
        property = {
        service = ConfigurationAction.class
public class SamplePortletConfigAction extends DefaultConfigurationAction {

// processaction,render and include methods

5) Add below property in module bnd file
-metatype: *
 6) Introduce config.jsp with all possible fields which you want to configure

 Now check your configuration icon and see if custom configuration is available or not for that specific portlet.

Interesting right !!!!!!!  Enjoy Learning Osgi :)

Overriding classes and properties using OSGi - DXP

Hello Friends,

Here i have published all possible ways to override Liferay classes and properties for which we were using hook in older Liferay version.


1) Create Custom portlet data handler

        property = {
        service = PortletDataHandler.class
public class SamplePortletDataHandler extends BasePortletDataHandler
// Override methods which you required to override

2) Create Custom Model Listner

        immediate = true,
        service = ModelListener.class
public class LayoutModelListener extends BaseModelListener<Layout>
 // Override methods which you required

3) Create Custom workflow handler

        property = {"model.class.name=com.sample.model.SampleEntity"},
        service = WorkflowHandler.class
public abstract class SampleWorkflowHandler extends BaseWorkflowHandler
 // Override methods which you required

4) Custom Action

        property = {
            "javax.portlet.name=" + PollsPortletKeys.POLLS,
            "javax.portlet.name=" + PollsPortletKeys.POLLS_DISPLAY,
        service = MVCActionCommand.class
public class CustomMVCActionCommand  extends BaseMVCActionCommand
 // Override methods which you required

5) Custom Render

        property = {
            "javax.portlet.name=" + PollsPortletKeys.POLLS_DISPLAY,
        service = MVCRenderCommand.class
public class CustomActionMVCRenderCommand implements MVCRenderCommand
 // Override methods which you required

6) Override Liferay Language Properties

        property = { "language.id=en_US" },
        service = ResourceBundle.class
public class ENResourceBundleComponent  extends ResourceBundle {

    protected Object handleGetObject(String key) {
        return _resourceBundle.getObject(key);

    public Enumeration<String> getKeys() {
        return _resourceBundle.getKeys();

    private final ResourceBundle _resourceBundle = ResourceBundle.getBundle(
        "content.Language", UTF8Control.INSTANCE);

7) Override Liferay Module Language Properties

    immediate = true,
    property = {
public class ResourceBundleLoaderComponent  implements ResourceBundleLoader {

    public ResourceBundle loadResourceBundle(String languageId) {
        return _resourceBundleLoader.loadResourceBundle(languageId);

    @Reference(target = "(bundle.symbolic.name=com.liferay.polls.web)")
    public void setResourceBundleLoader(
        ResourceBundleLoader resourceBundleLoader) {

        _resourceBundleLoader = new AggregateResourceBundleLoader(
            new CacheResourceBundleLoader(
                new ClassResourceBundleLoader(

    private AggregateResourceBundleLoader _resourceBundleLoader;


8) Override Liferay services

@Component(service = ServiceWrapper.class)
public class CustomUserLocalService extends UserLocalServiceWrapper {
// Override methods which you require   

Portal-ext.prioperties cannot be override through OSGi and you will have to manually update portal-ext.properties which we are keeping inside WEB-INF/classes

Liferay MVC Portlet with Service Builder - DXP


Here you will see how you can create Liferay MVC portlet with best practice.

If you remember, we were creating portlets in 6.X by selecting specific portlet type from IDE and choosing weather we have to use service builder or not. So there it was creating only one single portlet including service layer.

Now in DXP, you will have to separately create service layer and web portlet layer .
Now here we will have to keep 2 things in our mind.
1) Portlet specific service layer
2) Generic service layer (Which can be used across all the modules)

Identically both are same and the way of accessing the service also would be the same only difference is, if service is portlet specific then you can keep service and web layer altogether in single module project which will help for CI and build whole project.

1) Now here first step would be create new Liferay module by selecting servicebuilder as template and create.

You can also create this portlet using blade-cli tool as well.
You can use below command to create if you have install blade-cli in your local.

11 November, 2016

Issues During 6.X to DXP migration

There are couple of common problem which we might facing during migration or upgration from 6.X to Liferay DXP.

We will discuss all possible items over here.

27 September, 2016

Overriding LPKG Files : Liferay DXP

Liferay provides a way to update modules without modifying the original LPKG file they're packaged in. You can do this by overriding the LPKG file.
To override a JAR or WAR from any LPKG other than the Static LPKG, 

1) first create a folder named override in the Liferay instance's osgi/marketplace folder. 2) Drop the updated JAR into this folder, making sure its name is the same as the JAR in the original LPKG, minus the version info. For example, if you want to override the com.liferay.amazon.rankings.web-1.0.5.jar from the Liferay CE Amazon Rankings.lpkg, you would insert a JAR named com.liferay.amazon.rankings.web.jar into the osgi/marketplace/override folder.
3) Overriding JARs from the Static LPKG works the same way, but the updated JARs go into the osgi/static folder instead. For example, if you want to override the com.liferay.portal.profile-1.0.3.jar, you would insert a JAR named com.liferay.portal.profile.jarinto the osgi/static folder.

Note: To undo these changes, delete the overriding JAR; portal will use the original LPKG JAR on its next startup. Note that adding and removing JARs must be done while the portal is shut down. Changes take effect the next time the portal is started.

Source : https://github.com/liferay/liferay-portal/blob/master/tools/osgi-marketplace-override-README.markdown 

I am sure this would come across someday when you would like to override LPKG files for small/large scale changes.

22 September, 2016

6.X Portlet to DXP Module Convesion

Follow below steps to convert Liferay MVC Portlet to Module:

1)  First Step is, you will have to download plugin-sdk for DXP/Liferay 7 because Liferay has provided one tool which gives you facility to show breaking API changes in your portlet.

2) Once you run this tool, it will give you all the breaking Liferay API (Not Custom code) report for Java and JSP files.
 Note: Sometimes it doesn't work to generate report. So restart your IDE and try. it should start generating report after restart.

3) Now you can modify these files according to report and can check in plugin SDK it self weather this portlet is deploy-able or not.

4) Once you are done with this activity, you will have to convert your portlet into OSGi module.

5) Create Liferay MVC Portlet from Liferay developer studio (For DXP).
Note: If your portlet have service builder code then you will have to create module by selecting service-builder template.

 6) Now what you need to do is, you will have to copy manually your java classes into generated bundle/module.

 All converted Java classes will go to java folder and all jsp/jspf files will go to resource folder under META-INF.
If you have any Language property then it will be inside content folder.

7) Once you copy your code into generated bundle, you will have to check if any dependency it required and showing any import packages error. If it is then you will have to manually define dependency inside build.gradle file.
like I have added log4j in below snippet,
dependencies {
    compileOnly group: "com.liferay.portal", name: "com.liferay.portal.kernel", version: "2.6.0"
    compileOnly group: "com.liferay.portal", name: "com.liferay.util.taglib", version: "2.0.0"
    compileOnly group: "javax.portlet", name: "portlet-api", version: "2.0"
    compileOnly group: "javax.servlet", name: "servlet-api", version: "2.5"
    compileOnly group: "jstl", name: "jstl", version: "1.2"
    compileOnly group: "org.osgi", name: "org.osgi.compendium", version: "5.0.0"
    compileOnly group: "log4j", name: "log4j", version: "2.1.17"

8) You also will have to make sure that, if you have used any specific imports in JSP file then you need to modify that as well. Breaking API changes tool will give you this report if its liferay specific but if you have imported some custom code then need to check manually.

9) Once you able to compile your code successfully, just deploy that converted module by running gradle deploy task.

10) Now the most important thing is, though you are able to compile module, its not guarantee that your portlet will be deployed into container successfully and available to use.
 Note:You will have to check OSGi log from gogo shell and also will have to look into tomcat log if its throwing any specific import packages error or other errors.It should be in active stage.

11) If its deploy into container without any error then, you are done with the migration.

There are couple of items or checkpoints which you will be facing during module compilation or deployment.
I will try to collect all such kind of points ans solutions and will publish into separate post.

You can post your comment here for any such kind issue which we can discuss.

Stay tune with LiferaySolution.

DB Upgrade 6.X to DXP

Image result for Liferay upgradeAs you know Liferay is moved to DXP version now and all existing Liferay customer will migrate or upgrade to newer version of DXP.

Here in these series of  blogs, you will see all step by step guide which will help you to follow all the necessary steps for the migration to DXP.

As a part of migration/up-gradation, Database comes first everywhere which you must require to migrate to make it compatible with new version.

Here we will only talk about migration from 6.X to DXP as we will not consider the older version like 5.X.

20 September, 2016

Liferay DXP Setup

Image result for Liferay DXP
Follow below steps to setup local Liferay DXP :

Below Tools and software are required to setup Liferay DXP in local machine  :
A.    JDK-8
B.    JPM
C.    Blade
D.    Liferay DXP (Tomcat bundle)
E.    Liferay Plugin-SDK

16 August, 2016

Know Module And Component

The main reason for LIFERAY to move into module framework is,

  • Creating small modules (Tightly coupled)
  • Publish and consume other modules features (Inflexible)
  • Working without static dependencies (Dynamic dependencies)
To use module framework,
You mainly need to understand below 3 concepts :
  1. Modules
  2. Components
  3. Application Lifecycle 


Module is something which is group of Java classes, other optional resources, and a MANIFEST.MF file, packaged together as into a  single JAR file. Liferay 7 uses three modules/bundles.
Modules can have multiple components.


Component is nothing but implementation of interface like the way we were doing with *LocalServiceImpl class in older fashion. So here what you need to do is, you just will have to load components through annotations in implementation class.These loaded/declared components would be part of modules.

Here Lifecycle of modules and component will be handled through Liferay's OSGi based module framework.

What is OSGi ?

OSGi :  Open Service Gateway Initiative

OSGi is architecture to develop and deploy a modules in modular (Some times refers as Micro Services) application.
OSGi containers such as knopflerfish, Equinox and Apache Felix are responsible to divide and load your modules dependencies.

OSGi Specifications:
=> Set of services that OSGi container implements
=> Contract between your application and container

Benefits to use OSGi:

  • Easier to manage dependencies across module or plugin level
  • And the most interesting feature is,Modules can be installed and uninstalled during running server itself and no need to bounce the server.
  • module versionoing will helpful developers to reduce/stop class conflict for individual version of modules
  • Deployment would be quit easy once you understand the build and deployment process through blade tool
  • Service contract are loosely coupled. It means, services can be publish and consume from service registry.
  • Its very fast due to small and secure with small package/bundle.
  • One more interesting stuff here is, during development you dont need to be dependent on Liferay SDK untill and unless your module or individual project follows Liferay's OSGi standards.
  • In-short, this new framework will give very good flexibility to developer for the development and will increase productivity as well.
  • All application servers supports OSGi modules

Other Benefits I found from OSGi site which is very well explained :

Reduced Complexity - Developing with OSGi technology means developing bundles: the OSGi components. Bundles are modules. They hide their internals from other bundles and communicate through well defined services. Hiding internals means more freedom to change later. This not only reduces the number of bugs, it also makes bundles simpler to develop because correctly sized bundles implement a piece of functionality through well defined interfaces. There is an interesting blog that describes what OSGi technology did for their development process.

Reuse - The OSGi component model makes it very easy to use many third party components in an application. An increasing number of open source projects provide their JARs ready made for OSGi. However, commercial libraries are also becoming available as ready made bundles.

Real World - The OSGi framework is dynamic. It can update bundles on the fly and services can come and go. Developers used to more traditional Java see this as a very problematic feature and fail to see the advantage. However, it turns out that the real world is highly dynamic and having dynamic services that can come and go makes the services a perfect match for many real world scenarios. For example, a service could model a device in the network. If the device is detected, the service is registered. If the device goes away, the service is unregistered. There are a surprising number of real world scenarios that match this dynamic service model. Applications can therefore reuse the powerful primitives of the service registry (register, get, list with an expressive filter language, and waiting for services to appear and disappear) in their own domain. This not only saves writing code, it also provides global visibility, debugging tools, and more functionality than would have implemented for a dedicated solution. Writing code in such a dynamic environment sounds like a nightmare, but fortunately, there are support classes and frameworks that take most, if not all, of the pain out of it.

Easy Deployment - The OSGi technology is not just a standard for components. It also specifies how components are installed and managed. This API has been used by many bundles to provide a management agent. This management agent can be as simple as a command shell, a TR-69 management protocol driver, OMA DM protocol driver, a cloud computing interface for Amazon's EC2, or an IBM Tivoli management system. The standardized management API makes it very easy to integrate OSGi technology in existing and future systems.

Dynamic Updates - The OSGi component model is a dynamic model. Bundles can be installed, started, stopped, updated, and uninstalled without bringing down the whole system. Many Java developers do not believe this can be done reliably and therefore initially do not use this in production. However, after using this in development for some time, most start to realize that it actually works and significantly reduces deployment times.

Adaptive - The OSGi component model is designed from the ground up to allow the mixing and matching of components. This requires that the dependencies of components need to be specified and it requires components to live in an environment where their optional dependencies are not always available. The OSGi service registry is a dynamic registry where bundles can register, get, and listen to services. This dynamic service model allows bundles to find out what capabilities are available on the system and adapt the functionality they can provide. This makes code more flexible and resilient to changes.

Transparency - Bundles and services are first class citizens in the OSGi environment. The management API provides access to the internal state of a bundle as well as how it is connected to other bundles. For example, most frameworks provide a command shell that shows this internal state. Parts of the applications can be stopped to debug a certain problem, or diagnostic bundles can be brought in. Instead of staring at millions of lines of logging output and long reboot times, OSGi applications can often be debugged with a live command shell.

Versioning - OSGi technology solves JAR hell. JAR hell is the problem that library A works with library B;version=2, but library C can only work with B;version=3. In standard Java, you're out of luck. In the OSGi environment, all bundles are carefully versioned and only bundles that can collaborate are wired together in the same class space. This allows both bundle A and C to function with their own library. Though it is not advised to design systems with this versioning issue, it can be a life saver in some cases.

Simple - The OSGi API is surprisingly simple. The core API is only one package and less than 30 classes/interfaces. This core API is sufficient to write bundles, install them, start, stop, update, and uninstall them and includes all listener and security classes. There are very few APIs that provide so much functionality for so little API.

Small - The OSGi Release 4 Framework can be implemented in about a 300KB JAR file. This is a small overhead for the amount of functionality that is added to an application by including OSGi. OSGi therefore runs on a large range of devices: from very small, to small, to mainframes. It only asks for a minimal Java VM to run and adds very little on top of it.

Fast - One of the primary responsibilities of the OSGi framework is loading the classes from bundles. In traditional Java, the JARs are completely visible and placed on a linear list. Searching a class requires searching through this (often very long, 150 is not uncommon) list. In contrast, OSGi pre-wires bundles and knows for each bundle exactly which bundle provides the class. This lack of searching is a significant speed up factor at startup.

Lazy - Lazy in software is good and the OSGi technology has many mechanisms in place to do things only when they are really needed. For example, bundles can be started eagerly, but they can also be configured to only start when other bundles are using them. Services can be registered, but only created when they are used. The specifications have been optimized several times to allow for these kind of lazy scenarios that can save tremendous runtime costs.

Secure - Java has a very powerful fine grained security model at the bottom but it has turned out very hard to configure in practice. The result is that most secure Java applications are running with a binary choice: no security or very limited capabilities. The OSGi security model leverages the fine grained security model but improves the usability (as well as hardening the original model) by having the bundle developer specify the requested security details in an easily audited form while the operator of the environment remains fully in charge. Overall, OSGi likely provides one of the most secure application environments that is still usable short of hardware protected computing platforms.

Non Intrusive - Applications (bundles) in an OSGi environment are left to their own. They can use virtually any facility of the VM without the OSGi restricting them. Best practice in OSGi is to write Plain Old Java Objects and for this reason, there is no special interface required for OSGi services, even a Java String object can act as an OSGi service. This strategy makes application code easier to port to another environment.

Runs Everywhere - Well, that depends. The original goal of Java was to run anywhere. Obviously, it is not possible to run all code everywhere because the capabilities of the Java VMs differ. A VM in a mobile phone will likely not support the same libraries as an IBM mainframe running a banking application. There are two issue to take care of. First, the OSGi APIs should not use classes that are not available on all environments. Second, a bundle should not start if it contains code that is not available in the execution environment. Both of these issues have been taken care of in the OSGi specifications.

22 July, 2016

Sharepoint REST API call

Guys, I am sure this snippet will help you a lot when you do sharepoint REST integration to read files

30 March, 2016

Useful Roles and permission API

Reading portlet resources and model resources:
List<String> portletResources = ResourceActionsUtil.getPortletResourceActions(PortletLocalServiceUtil.getPortletById(portletId).getPortletId());

List<String> modelResource = ResourceActionsUtil.getPortletModelResources(portletId);

09 March, 2016

OpenAM (OpenSSO) + Liferay 6.2

We are starting OpenAM integration by considering we have setup OpenDJ with Liferay. See http://www.liferaysolution.com/2016/03/opendj-liferay-62.html

Install OpenDJ

2)  You can deploy this war file in the same tomcat where your liferay is runinng or you can deploy in separate tomcat server (apache-tomcat-7.0.68). My recommendation is , use separate tomcat server for that

3) For our comfort, rename war file from OpenAM-11.0.0.war to OpenSSO.war and start tomcat server for deployment

4) Once it's deployed into tomcat, you can access it through  http://jignesh.openam.com:7070/OpenSSO. Here jignesh.openam.com:7070 is the host name which i configured for newly installed tomcat server.
Also make sure that server have enough JVM memory allocation using below line in startup.bat
set JAVA_OPTS=-Dfile.encoding=UTF-8 -Xms128m -Xmx1024m -XX:PermSize=64m -XX:MaxPermSize=256m

OpenDJ + Liferay 6.2

Follow below steps to integrate OpenAM & OpenDJ with Liferay 6.2 :

Install OpenDJ :

2) Extract OpenDJ-3.0.0.zip and Click on setup .bat file to do a setup of OpenDJ

3) Click next and check mark the accept checkbox
4) Server Setting Screen :
FQHN : opendj.jignesh.com
LDAP listner port : 389
Administrator connection port : 4444
Root User DN: cn=Manager
password : test

11 February, 2016

Liferay 7 : Open source OSGi containers

If you want to develop complex web application and if you want to break up the application in various madules like one for DAO Layer, view layer and data access layer.
Using OSGi container, you can manage cross dependencies between all these modules and deploy this is also without restarting the server.

If you application is OSGi compliant, you should be able to run your application in any of the below open source OSGi container :

1) Apache Felix
2) Equinox
3) Knopflerfish

For Liferay 7, We are going to user Apache Felix across all the implementation.

05 January, 2016

JSON Web Service


You may be aware that Liferay provides facility to expose remote service in form of REST and SOAP.

Popular Posts

Featured Post

Liferay 7.3 compatibility matrix

Compatibility Matrix Liferay's general policy is to test Liferay Portal CE against newer major releases of operating systems, open s...