Friday, November 28, 2014

Liferay Plugin Applications Deployment Process Details

We have different kind of liferay applications such as plugins and exts.
Coming to plugins we have portlets,hooks,themes,layouts and webs.

Install/Deploy Liferay Applications.

Web Applications Deployment

Deployment is a process in web application to place application archive files(WAR, EAR) in application server deployment directory and start the the application.

Deployment directory is place in application server there all the web application are reside and running from there.

Based on application server the deployment directory may be change, lets say in Tomcat Server deployment directory is “webapps” (tomcat-7.0.42/webapps). Jboss “deployments” (jboss-7.1.1/standalone/deployments) is deployment directory.

Applications Archive Files

Generally in web application development we will package all artifacts such as files, Java classes, configuration files, properties file,deployment descriptors and requires libraries and its directories as archive files.

In J2EE development of web application we can see two kinds of Archive Files such as EAR(Enterprise Archive Files) and WAR (Web Archive Files).

EAR(Enterprise Archive Files) are related Enterprise Java Beans Technology based packaging and its required EJB containers to run those applications.

WAR (Web Archive Files) are related to J2EE based Technology web application packaging and it also required respective containers to run the applications.

.WAR file:

After package the web application artifact in single archive and these files extension always be .war(HelloWorld.war,Sample.war)

Generally Application Server recognize the .war extension file so that it will process required steps to run the application.


Based on server properties web archive files(.war) file will be unpackaged/exploded once it placed in server deployment directories.

To run any J2EE web applications they need respective technology based containers to provide run time environment to the applications.

Generally when we deploy web applications we need to stop server and restart the server to see the changes in the application.

Assume we are deploy the applications in production servers so its not good to down/stop servers. This is where we have a concept called “Hot Deployment”.

Hot Deployment:

Hot Deployment is one of the web applications deployment process where we don't need to stop servers while deployment of web applications and it will start the applications and we can see changes at run time.

In the process of Hot Deployment there is specialized directory to place web archive files instead of directly placing into server deployment directory.

Assume we have web application we want deploy into different application servers and each application deployment process is different and we may need to add some other configuration or supported libraries to make successful deployment. This is typical task to deploy in different servers, to make this work easy we have process called “Auto Deployment”

Auto Deployment

Auto deployment is one web application deployment process there we can deploy web application into different application server and required server dependent configuration and libraries will be added automatically to make successful deployment of application.

Liferay Deployment Details

Liferay also support two deployment capabilities such as Hot Deployment and Auto Deployment.

Liferay Hot Deployment:

Hot Deployment process we can see in the J2EE severs environment and we will place the application archive files(WAR,EAR) files in specially configured directory and application server (Tomcat, WebSphere, WebLogic, etc.) picks up that artifact, deploys it within the application server, and starts the application

We already know liferay is also web application and its also packaged as
.war file.
To support “Hot Deployment” Liferay Server Bundle have one directory called “deploy” directory.

Deploy” directory will be in “Liferay Home” directory. We will deploy liferay archive files in “deploy” directory and as soon as we placed web archive file in deploy directory then Hot Deployment scanner pick the file and placed in server deployment directory in addition to this it will add required configuration to the application.

Hot deployment is good for development environment and deploy liferay applications in single server production environment and in this mode we need not restart server.

Liferay Hot Deployment have limitation it wont work in multi-node production deployment and we have many constraints to deployment liferay applications in multi node server environment.

When we work with Multi Node/Multi Server production Environment we should make sure following things

Web Application Archive File should be available to all servers
Application should deploy successfully in all servers simultaneously

In the multi server production environment we need design deployment architecture so that it will complete deployment in all servers successfully.

Generally we will use Admin Servers it will take to deploy application in all remaining serves successfully and simultaneously this is called master and slave architecture.

Application server provide different tools or admin console to do hot deployment job in all servers.

JBoss “domain” mode

WebLogic “production” mode

WebSphere deployment manager

Tomcat FarmWarDeployer

These modes and tools reside completely outside of Liferay Portal and are strictly in the application server’s realm. However, Liferay piggybacks off the application server’s hot deploy capability and performs additional initialization after a given application starts (e.g., via javax.servlet.ServletContextListener mechanisms).

We have different types of liferay plugin applications and all plugins have hot deployment capabilities. If we deploy any liferay Plugin applications such as portlet, hook,theme,layout and web then we need not start server and the change will be applied.

There are some specific Liferay capabilities that won’t work unless your application server has hot deployment capabilities. Specifically, hot deploying custom JSPs in hooks won’t work, because Liferay’s JSP hook overriding capabilities depend on the application server’s ability to: 

Deploy based on an exploded portal WAR
Load changes to JSP files at runtime

Generally when we deploy web archive(.war) files in servers these web archive files are unpackaged/exploded in the server deployment directory in the process successful deployment this kind of behavior we will use mostly in local development environment.

In the production/domain environment don’t use unpackaged/exploded WARs because of these some of liferay hooks not support hot deployment capabilities such as Custom JSP hook. Production servers don’t support JSP reloading/recompilation in these modes. Even for Tomcat, it’s generally advisable to deactivate JSP reloading for production deployments.

So what do you do if you use hooks to override Liferay JSPs AND you must use non-exploded WAR deployments? The answer is simple: inject a pre-processing stage as part of your build process. You deploy the hooks, allowing them to make changes to the portal WAR file. Then you re bundle the portal WAR file and deploy it using the application server’s deployment tools. Of course, you still need to deploy your hook as well, but you no longer need to worry about the JSP overrides not being loaded by your application server.

Liferay Auto Deployment:

Liferay Auto deployment process is similar to hot deployment and its injecting required jar files and deployment descriptors into web application archive file at time of deployment. Liferay auto deployment also have capabilities of hot deployment capabilities. Executing ant deploy invokes both hot deployment and auto deployment tasks for your plugin.

In the process of Auto Deployment the followings task will be takes place.

Picks up a Liferay recognized archive (e.g., *-portlet.*, *-theme.*, *-web.*, *.lpkg)

Injects required libraries (e.g., util-java.jar, util-taglib.jar)

Injects dependent JAR files (specified in

Injects required taglib descriptors (e.g., liferay-theme.tld)

Injects required deployment descriptors (e.g., app server specific descriptors)

Injects any missing Liferay specific deployment descriptors (e.g., liferay-portlet.xml)

Auto deployment helps us to successful deployment in different server environment because it will automatically add server depended deployment descriptors at time of deployment.

Liferay Auto deployment also not compatible in the multi-node production environments Do not use the auto deployment method at runtime; use it at build time.

Generally when we use ant deploy then it will invoke auto deployment tasks and we have another ant target ant direct-deploy and The direct-deploy Ant task creates an exploded WAR from which you can easily create a WAR file. The location of the exploded WAR depends on the deployment directory of the application server you’ve configured in your Plugins SDK environment

ant direct-deploy create war file and inject all required jar files and server dependent deployment descriptors then it will directly placed war file in application server deployment directory and server deployment directory information configure in file.

The Plugins SDK’s provides a default deployment directory value for each supported app server. But you can override the default value by specifying your desired value for the app.server.[type].deploy.dir (replace [type] with your app server type) in your build.[username].properties file.


app.server.tomcat.deploy.dir = /opt/LiferayWorkSpace62/bundles/tomcat-7.0.42/webapps

Important Points

Liferay Plugin applications support hot deployment capabilities so we need not to start application server while deployment and changes will be applied directly.

Liferay Plugin Applications are packaged as web archive files that is .war file and liferay application also packages as .lpkg When we download any application from liferay market place we can see portlet application extension as .lpkg and internally .lpkg contains one or more .war files.

When you want deploy external liferay application such as .war or .lpkg then we simply place these files in liferay “deploy” directory and this is available in “Liferay Home” or we can change these directory path with the property auto.deploy.dir = ${app.server.parent.dir}/deploy this property in file of your Plugins SDK and you can override this property in build.[username].properties file

Liferay hot deployment should be supported by application server then only liferay applications can inherited those capabilities.

Liferay Hot deployment can be successfully work in development environment and single node production environment and these capabilities are not compatible in multi node server environments.

All applications build related properties are available in Plugins SDK files there you can choose server environment and other environment related properties and we can also override these properties in build.[username].properties file.

Liferay Auto deployment process will take caring packaging application, inject required jar filed and server supported deployment descriptors and then deploy into application servers.

Liferay Auto deployment is also successfully work in development and single node production environment and its not compatible in multi-node production server environment.

Each Liferay Plugin Application have different ant task such as ant deploy and ant direct-deploy. When we run ant deploy then it will invoke auto deploy and hot deploy tasks.

ant deploy” target perform tasks such as package as web archive file,inject required jar files then place the war file in liferay “deploy” directory. As soon as application war file placed in deploy directory then hot deployment scanner will perform necessary steps to complete the application deployment success.

ant direct-deploy” target perform tasks such as package as web archive file,inject required jar files and inject server dependent deployment descriptors then place the WAR file in server deployment directory.

Liferay development in development environment and single node production environment is pretty straight forward way but when we work with production environment and multi-node server environment we need to put some additional effort to complete successful deployments.


Wednesday, November 26, 2014

Portlet Introduction / Portlet Technology Introduction

Portlet is small fragment of dynamic content in the web page. And this dynamic content may be text,HTML,xml or some other MIME format. Portlet technology implemented by JSR 168 and JSR 286 standards.

Generally in web application we are very familiar with servlet technology and portlet technology is similar to servlet technology but it consist its own features. servlet technology based on client and server architecture in the web world here the client is browser.

Portlets life cycle is managed by portlet containers these are in application servers. portlet life cycle consist different stages like instantiation,serving and destroying. Portlet containers are similar to servlet containers to manage entire life cycle of portlet.

Generally in the portlet technology each page consist one or more portlets and each portlet render dynamic content to make complete web page.

In technical understand portlet technology implemented in Java in the package javax.portlet.

This portlet API consist many interfaces and implementation classes to developed portlet based application in the web world.

How does portlets are differed from servlet

Generally in servlet web application each servlet will be referred by URL to invoke or access and each web page content will be served by one servlet but in portlets each page will be served by different portlet and each portlet will have its own lifecycle and own URL pattern to execute.

Servlet will generate dynamic content which send to browser and it’s in single web page but portlet will server fragment of dynamic content and portal page is responsible to aggregate content from different portlet to generate whole page.

There are many people implemented the portlet technology.


Understanding the Portlet Technology

Basically we need to following things to run portlet based application

Portlet Container+Application Server

Portlet Container

Portlet containers is responsible for run the portlet and it provides the required run time environment. Portlet containers manage the life cycle of portlets. When ever portal server send the request then portlet containers receive the requests and its invoke the respective portlet to process request means its instantiated the portlet and execute appropriate life cycle methods to prepare response. Portlet container send portlet response back to portal server like that portal server receive responses of different portlets and aggregate all response to complete client request.

Application Server

Application servers are responsible to process client request and send response back to client. Application server provided different services to manage and run web applications. The services like JMS, JNDI, JTS, JAAS, JDO,Connection Pooling and all these services required by the applications.

Application servers integrated with different containers to provide different run time environments like servlet containers to provides run time environment to execute servlets, portlet containers is to provides the run time environment to execute portlet, EJB containers to provided environment to execute Enterprise Java Beans applications.

Apart from this application severs have more capabilities to provide different services to run different technology based applications.


As we already know each portlet has it own life cycle and which will be managed by portlet container. According to the JSR 168 standard portlet have three life cycle stages.

Basic portlet consist following life cycle stages

Portlet life cycle  


Initialize the portlet and put the portlet into service

Handle requests:

Process different kinds of action- and render-requests


Put portlet out of service

Theoretically we have 3 life cycle stages in portlets and these will be implemented via portlet interface. Portlet interface is implemented in javax.portlet package by Sun Microsystems.

Every portlet that should implements the portlet interface or it should extend the class that already implemented the portlet interface.

As we know portlet have three life cycle staged and the following are interface methods which handle portlet life cycle in portlet implementation.

init(PortletConfig config):

This method is initialize the portlet and this will be called only once when portlet is instantiated, we can say when we drag and drop portlet in page.

If any necessary functionality required at initial time of portlet we will use this method and write code here. It is similar to servlet init method. This method can be used to create expensive objects/resources used by the portlet.

processAction(ActionRequest request, ActionResponse response):

When user is requested to server then portlet will execute process action method.
This method will notify the portlet that used has triggered an action this portlet. , a portlet can issue a redirect, change its portlet mode or window state, modify its persistent state, or set render parameters.

render(RenderRequest request, RenderResponse response):

Render method will generate content and that will be send to web client.
In the portal page we have many portlet we have triggered action in one portlet then all portlet will be executed render method to aggregate dynamic content. The portlet can produce markup that may depend on the portlet mode or window state, render parameters, request attributes, persistent state, session data, or backend data.

destroy ():

Indicate to the portlet the life cycle's end. This method allows the portlet to free up resources and update any persistent data that belongs to this portlet.


In the portlet life cycle for each action or request the final method is render method. Render method will be called for every time to aggregate content or produce content.

Generally portlet have different URL to call these methods like Action URL and Render URL. 
Action URL will execute portlet porcessAction(----) method and then it will be execute the render(----) method.

Render URL will execute the portlet render (---) method only. 

Portlet Lyfecycle Execution Process 

Portlet Characteristics

Portlet have addition Characteristics when we compare with servlet.

Portlet Widow States:

Portlet has different window states. Window state specifies how portlet will look in the page .Window state decides how much space will be accommodated in portlet page.

The following are important window states as for JSR 168 Standards.


When portlet state is decided as Maximized then entire page only one portlet is visible.
Generally we will use this state after perform some action then we will make widow state is Maximized.


Specified that is portlet may share the page with other portlets. This is the default window state.


Portlet should only render minimal output or no output at all.

Portlet Modes:

Portlet mode specifies that the function will be performed by portlet.
Generally following are the portlet modes that each portlet should support as for JSR 168&286 standards.


This view mode is when portlet is access or render then portlet is in view mode and this is default mode for portlet.


Edit mode will be used to edit some portlet functionality and generally we wil use this mode for administrator to modify or edit something.


This will used to provide content to end user about portlet i.e how to use and access portlet like help information. 
Persistent storage for preferences:

Portlets provide a Portlet Preferences object for storing user preferences. These preferences are stored in a persistent data store, so they will be available across server restarts. As a developer, you don't have to worry about the actual implementation of how it is stored.

Portlet Sessions:

Like Http Session in the portlet technology also have different scopes of session to share data among the portlet or with in the portlet. Portlet also can use Http Session.

Portlet Session by default scope is portlet level what ever the data stored in Portlet Session can be available with in portlet. If we want share data among the portlets then we have to use application level scope so that data can be shares across the portlets.

Portlet technology have concept called publics render parameters to exchange data among portlets this is we can all it as Inter Portlet Communication.

We can use portlet sessions or public render parameters to establish communication among portlets which are in same page.

Portal context 

Portal context provides information such as the portal vendor, the portal version, and specific portal properties. The information allows the portlet to use specific vendor extensions when being called by a portal that supports these extensions and, when being called by other portals, to return to some simpler default behavior.


Properties communicate vendor-specific settings between the portlet and portlet container, and between the portlet and the portal. 

These properties show up in several places in JSR 168. The portlet can read String properties with getProperty() from: 

ActionRequest, to receive properties that are action-request specific

RenderRequest, to receive properties that are render-request specific

PortalContext, to receive properties that are portal specific and do not change for different requests 

The portlet can write String properties with setProperty() to: 

ActionResponse, to set properties in response to an action request

RenderResponse, to set properties in response to a render request

Packaging and deployment

Portlet are packages as web archive file(WAR) this archive file consist of portlet deployment descriptors, resources and other java libraries which are required by portlets.

In the portlet application we have two deployment descriptors that is web.xml and portlet.xml

web.xml specifies the things related to web application deployment properties

portlet.xml specifies the portlet application related deployment properties and it always describes only one specific portlet application.

portlet application deployment is a two-step deployment that deploys the Web application into the application server and the portlets into the portal server.


Tuesday, November 25, 2014

Liferay Portlet Configuration Page in Plugin Portlet

Liferay configuration page provides a way to store portlet related configurations.
Generally in the development we may need to store portlet specific configurations and we need one user interface page to input some values and store into database. These portlet specific configuration will be stored in portlet preferences table.

To input these values we will use portlet configuration page there we can design user interface to submit values and page can be access through portlet configuration icon that is at top right corner of portlet it can see visible when we drag and drop the portlet in the page.

Assume Scenario:

In our custom portlet we want to display Site specific users in the portlet. We will store Site Id in portlet preferences and we will take site Id to get site ,form the site we will fetch users to display it in the table.

to set these portlet configuration we will use portlet configuration page there user will change site so that user selected site will be stored in portlet preference.

Portlet Configuration Page Implementation Steps.
  1. Create configuration JSP page
  2. Implement Custom Configuration Action Class
  3. Configure Configuration Action Class in liferay-portlet.xml
Create configuration JSP page

First we need to create portlet configuration page and there use will input data.
Create form and create requited input elements.

In our case we only need select box that should display all sites form there user will select one option.

We should create configuration action URL using <liferay-portlet:actionURL/> tag and we should use "portletConfiguration" attribute value as “true”

Example Configuration Action URL

<liferay-portlet:actionURL var="portletConfigurationActionURL" portletConfiguration="true"/>

When we submit form using above URL then it will invoke Custom Configuration Action Class

Implement Custom Configuration Action Class

We need to implement Custom Configuration Action class there will capture portlet configurations and will stored as portlet preferences.

Our Custom class should implments the ConfigurationAction interface and in the render method we need to specify the configuration JSP page path that was created in the first step.

We have processAction(--) method there will write configuration values storing logic and render(---) method we simply specify the portlet configuration jsp page path. We will use portlet preference to store the configuration values.

Example Syntax:

public class PortletConfigurationAction implements ConfigurationAction {
public void processAction(PortletConfig portletConfig,
ActionRequest actionRequest, ActionResponse actionResponse)
throws Exception {
public String render(PortletConfig portletConfig,
RenderRequest renderRequest, RenderResponse renderResponse)
throws Exception {
return "/html/portletconfiguration/portlet_configuration.jsp";

Configure Configuration Action Class in “liferay-portlet.xml”

Finally we need to configure the Configuration Implementation java class in liferay-portlet.xml file. We need to give Java class with complete package where it is reside.

The following is tag to configure portlet configuration class


The following is complete code example for portlet configuration

Create liferay Plugin portlet using Liferay IDE and add following jsp pages and java classes then you can be ready with portlet configuration page.

init.jsp (/html/portletconfiguration/init.jsp)

<%@page import="com.liferay.portal.kernel.util.Validator"%>
<%@ taglib uri="" prefix="aui" %>
<%@ taglib uri="" prefix="liferay-portlet" %>
<%@ taglib uri="" prefix="liferay-security" %>
<%@ taglib uri="" prefix="liferay-theme" %>
<%@ taglib uri="" prefix="liferay-ui" %>
<%@ taglib uri="" prefix="liferay-util" %>
<%@ taglib uri="" prefix="portlet" %>
<%@ page import="com.liferay.portal.kernel.util.Constants" %>
<%@ page import="com.liferay.portal.kernel.util.GetterUtil" %>
<%@ page import="com.liferay.portal.kernel.util.ParamUtil" %>
<%@ page import="com.liferay.portal.kernel.util.StringPool" %>
<%@ page import="com.liferay.portal.util.PortalUtil" %>
<%@ page import="com.liferay.portlet.PortletPreferencesFactoryUtil" %>
<%@ page import="javax.portlet.PortletPreferences" %>
<%@ page import="javax.portlet.WindowState" %>
<%@ page import="javax.portlet.PortletURL"%>
<%@ page import="javax.portlet.ActionRequest" %>
<%@ page import="javax.portlet.PortletPreferences" %>
<%@ page import="com.liferay.portal.kernel.language.LanguageUtil" %>
<%@ page import=""%>
<liferay-theme:defineObjects />
<portlet:defineObjects />
String currentURL = PortalUtil.getCurrentURL(request);
PortletPreferences preferences = renderRequest.getPreferences();
String portletResource = ParamUtil.getString(request, "portletResource");
if (Validator.isNotNull(portletResource)) {
preferences = PortletPreferencesFactoryUtil.getPortletSetup(request, portletResource);
String siteId = preferences.getValue("siteId","1");

portlet_configuration.jsp (/html/portletconfiguration/portlet_configuration.jsp)

<%@page import="com.liferay.portal.model.Group"%>
<%@page import="java.util.List"%>
<%@page import="com.liferay.portal.service.GroupLocalServiceUtil"%>
<%@page import="com.liferay.portal.service.GroupLocalService"%>
<%@page import="com.liferay.portal.kernel.util.Constants"%>
<%@include file="init.jsp" %>
List<Group> list=GroupLocalServiceUtil.getGroups(0,GroupLocalServiceUtil.getGroupsCount());
<liferay-ui:success key="potlet-config-saved" message="Portlet Configuration have been successfully saved" />
<liferay-portlet:actionURL var="configurationActionURL" portletConfiguration="true"/>
<aui:form action="<%=configurationActionURL%>" method="post" name="configurationForm">
Select Site:<br/>
<aui:select name="siteId" id="siteId">
<%for(Group group:list) {%>
<aui:option value="<%=group.getGroupId() %>" label="<%=group.getName() %>"></aui:option>
<%} %>
<aui:button type="submit" name="Save Configuration" value="Save Configuration"></aui:button>

view.jsp (/html/portletconfiguration/view.jsp)

<%@page import="java.util.ArrayList"%>
<%@page import="com.liferay.portal.model.User"%>
<%@page import="java.util.List"%>
<%@page import="com.liferay.portal.service.GroupLocalServiceUtil"%>
<%@page import="com.liferay.portal.service.UserLocalServiceUtil"%>
<%@page import="com.liferay.portal.service.UserLocalService"%>
<%@include file="init.jsp"%>
List<User> users=new ArrayList<User>();
long longSiteId = GetterUtil.getLong(siteId);
String SiteName="";
users = UserLocalServiceUtil.getGroupUsers(longSiteId);
}catch(Exception e){


<h3>Selected Site "<%=SiteName%>" Users</h3>
<table border="1">
<th>User First Name</th>
<th>User Last Name</th>
<th>User Screen Name</th>
<th>User Email Address</th>
for (User userobj : users) {

</table> (

package com.meera.portletconfig;
import javax.portlet.ActionRequest;
import javax.portlet.ActionResponse;
import javax.portlet.PortletConfig;
import javax.portlet.PortletPreferences;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import com.liferay.portal.kernel.portlet.ConfigurationAction;
import com.liferay.portal.kernel.servlet.SessionMessages;
import com.liferay.portal.kernel.util.ParamUtil;
import com.liferay.portlet.PortletPreferencesFactoryUtil;
public class PortletConfigurationAction implements ConfigurationAction{
public void processAction(PortletConfig portletConfig,
ActionRequest actionRequest, ActionResponse actionResponse)
throws Exception {
String siteId = ParamUtil.getString(actionRequest, "siteId");
String portletResource = ParamUtil.getString(actionRequest,"portletResource");
PortletPreferences preferences = PortletPreferencesFactoryUtil.getPortletSetup(actionRequest, portletResource);
preferences.setValue("siteId", siteId);;
public String render(PortletConfig portletConfig,
RenderRequest renderRequest, RenderResponse renderResponse)
throws Exception {
return "/html/portletconfiguration/portlet_configuration.jsp";



Download portlet from following location

In download you can see source code and war file you can use war file to deploy directly in your portal server and this portlet was developed using Liferay 6.2 Plugins SDK.

Usage of portlet

Download portlet and deploy the portlet in your portal server

Login as Administrator then add portlet to page which is available in Sample Category with name Portlet Configuration

Go to Portlet configuration page click on portlet configuration icon then you can see portlet configuration page.

Select site name then save the configurations

 Finally selected site users will be displayed in the portlet view page and we can change site name when ever we want like simple go to configuration page select the site name.

Recent Posts

Recent Posts Widget

Popular Posts