Total Pageviews

Saturday, April 5, 2014

Liferay: Connecting Portlet to an External Database Table

Sometimes we need to fetch data from two different databases in one project. There are several approaches, such as creating a new hibernate/spring session or fetching through web services. Both have their advantage and disadvantages. This article explains how we can create another session for fetching data from a database which is not configured as the portal's default database, but as some other (custom).
The problem with this approach is with the table creation, which is Liferay's obvious behavior. Why? I'll explain this in the end of this article.

1. First of all, create a new portlet with a service.xml file. Now build the service. For example, we create the following service. Here we need to know that the data-source value specifies the target data source which is the persistence class. The session-factory value specifies the session factory which is also set to the persistence class.The tx-manager value specifies the transaction manager which is used by Spring services. Rest of the things are pretty standard.

2. As we have built the service, Now its time to create table in the external database we're going to connect our portlet.

3. Now we have to supply the database connection details to our code. We can hardcode the database connection details directly in XML file directly, but its handy if  use the approach Liferay uses, i.e. through property file. So, lets just create some custom entries in file, not to mention you have to change the connection details as per your's:
4. As connection details now available, we have to use them to create a new session. So, for this we have to do spot the spring-ext.xml file which gets generated as soon as we build the service. The path of this file is: \docroot\WEB-INF\src\META-INF. We have to add the following entries in the end of this file:
Now we are done. We can now simple write LocalServiceInple code to access data from external database's table.

For the security reason, Liferay does not allow to create new table ontside the default DB. If you want to analyze liferay SRC, you can see the ServiceBuilder class's _createSQLTables method, where there is a condition check for default database.

You can download sample portlet from here. Hope this article will help you.

Thursday, August 15, 2013

A Note of Liferay Portlet URLs

In a portlet, we get our code executed by two ways - at the time of rendering of the portlet and another on some action which is generally a form submit or some event. For getting the same done, we have three different URLs in Liferay:
  1. Render URL (which is portlet URL and responsible for rendering of the portlet and in typical MVC portlet, the code of method doView() is executed)
  2. Action URL (which is also portlet URL and responsible for performing some action with page reload and in typical MVC portlet, the code method processAction() is executed, and is followed by renderRequest)
  3. Resource URL (which is NOT a portlet URL but it extends the same base URL, is responsible for performing some action without page reload i.e. Ajax and in typical MVC portlet, the code of method serveResource() is executed and is NOT followed bt render request, Resource Serving was not available in JSR168 but its avaible in JSR286.
We can create these URL mainly by four approaches:
  1. Using TagLib
  2. Using Java
  3. Using Javascript (AUI)
  4. Using Velocity

Now we'll see how we can create these three type of URLs with the above four approaches considering that you have done all necessary imports:

1. Using Taglib

Render URL:
here we are setting the window state of the portlet to maximum and a custom parameter(message).
Action URL:
Resource URL:

2. Using Java

Render URL:
Using RenderResponse:
Using PortletUrlFactory:
Action URL:
Using RenderResponse:

Using PortletUrlFactory:
Resource URL:
Using RenderResponse:
Using PortletUrlFactory:

3. Using Javascript (AUI)
Render URL:

Action URL:

Resource URL:

The following can be set on these portlet URL methods:
  • setCopyCurrentRenderParameters: function(copyCurrentRenderParameters);
  • setDoAsUserId: function(doAsUserId);
  • setEncrypt: function(encrypt);
  • setEscapeXML: function(escapeXML);
  • setLifecycle: function(lifecycle);
  • setName: function(name);
  • setParameter: function(key, value);
  • setPlid: function(plid);
  • setPortletConfiguration: function(portletConfiguration);
  • setPortletId: function(portletId);
  • setPortletMode: function(portletMode);
  • setResourceId: function(resourceId);
  • setSecure: function(secure);
  • setWindowState: function(windowState);
  • toString: function();

4. Using velocity: Here we have to replace correct portletId and plid for getting the URL generated correctly.
Render URL:
Action URL:
Resource URL:
Hope you enjoyed the read.

Monday, July 22, 2013

A Note of Liferay Portal Instances

Liferay provides us facility to run more than one portal instance on a single server. Liferay comes with one inbuilt portal instance, which is names 'Liferay' and its web id is '', however it can be modified with following properties in file:
Note: There are several other properties regarding portal instances present in as well which can be referred in Liferay Portal SRC.

If we login as administrator (generally, and go to control panel we can see list of all available portal instances in 'Portal Instances' section inside 'Server' category. Here we will see a table with atlest one entry (inbuilt one) , lets know what the column of this table depicts:

  • Instance ID: It’s a numeric Id, generated by code automatically at the time of Instance creation. Internally this Instance ID is referred as 'companyid' in the database table. We can see all available instances in database table 'company'.
  • Web ID: It’s a user-generated ID for the instance. It can be anything relevant but a general convention is to use the domain name.
  • Virtual Host: Domain name which is to be configured in the network kept here. This domain name is referred when users are directed to our Liferay server, and the same enables Liferay to resolve request for proper portal instance.
  • Mail Domain: The domain name to be used as mail host for this instance kept here. Liferay will use this to send email notifications from the portal, and the same is used for creating the default test user, as
  • # of Users: Depicts current number of users on particular portal instance.
  • Max # of Users: Depicts total number of users allowed on particular portal instance.
  • Active: Depicts if the portal instance active or not (Yes / No).

Enough of theory, lets experience it. Startup the server and replicate the following steps:
  1. Login as administrator. ( will work)
  2. Navigate to Manage → Control Panel → Portal Instances section in 'Server' category.
  3. By default only one portal instance will be listed. To add new, click on add button fill up the form fields. Say you have created ''.
  4. Assuming that you are working on your local system, you have to edit the host file (%SYSTEMROOT%\ System32\ drivers\ etc\ hosts). Add the following in the file:
    If you are in network then you can map the entry with the IP address of the server on which Liferay is running and try.
  5. Start the browser (restart in case already running) and put '<PORT>' in address bar. What you see now in the new portal instance.
  6. You can login as test@<domainname>, ( in out case). This is the admin user of the instance. As an administrator you cannot see the 'Server' category in Control Panel, which means new instance can be created only from main portal instance.
If we dig in further, we will come to know that we can have different properties file for each portal instances. To enable this feature, set the "company-id-properties" system property to true. The read order will now be:, then, and then Note that not all properties can have different values per company. This functionality is only available for legacy reasons. The preferred way to configure a portal instance is through the Control Panel.

Handling Portal Instances in Custom Code:
In real life scenario, we may need to process data differently for each Portal Instance in our custom code. So have a look on small code snippet:
Hope you enjoyed the reading.