Total Pageviews

Saturday, October 11, 2014

Liferay: Instance Specific 'portal.properties' File

To start with this topic, we need to refresh the following:

Portal-ext.properties
Everybody who works with Liferay, know about portal-ext.properties file. Just to refresh, this file contains key-value pairs of settings and is present in the classpath to override the properties of portal.properties file (can be seen in Liferay source code or portal-impl.jar).

Liferay Portal Instance
Liferay Portal allows you to run more than one portal instance on a single server (e.g. tomcat instance). The Portal Instances page of the control panel lets you manage these instances. All portal data, however, is kept in the same database. (You can read in details here)

As a standard practice, the settings we do in portal-ext.properties file are shared among all portal instances. But with the settings we are now going to discuss will allow us to create different property files for each portal instance, and this is out of box only. To do so, we have to do the following two settings:

1. There are two ways of doing this, first you can set the following property in your system.properties file

or you can set this in your setenv.bat or setenv.sh as per your environment. You can enter the above entry just after '-Duser.timezone=IST' in the file.

2. Now we have to create properties file with the naming format 'portal-<<WebId>>.properties'. For instance, if the web id of the instance is 'finance', then the name of the property file for this instance will be portal-finance.properties.

Similarly we can create different property files for other portal instances. The default web id of liferay instance is 'liferay', so the name of property file for this instance will be 'portal-liferay.properties'.

Important things to note here is - not all properties can be overridden by this setting. Properties such as database configurations should be in the property file of default instance only.

For testing this, you can try to modify the authentication method. Change the value to screen name in the second instance's properties file while keeping the email (as default come bundled), you will get the second instance authenticating with screen name while the first with email address. It also works well while fetching the values using PropsUtil API. 

Saturday, August 2, 2014

Liferay:Quick Reference to Asynchronous Message Bus

There are needs in practical scenario when it’s needed to do some huge processing in the background. It’s like some command is given to do something, while the application is not waiting for the response, such as sending bulk emails, handling scheduler’s requests, processing some data etc. Asynchronous message bus is great way to achieve this kind of requirement in Liferay.

The Message Bus is a mechanism for sending message payloads to different components in Liferay, providing loose coupling between message producers and consumers to prevent class loading issues. It’s located in the global class loader, making it accessible to every deployed web application. Remote messaging isn’t supported, but messages are sent across a cluster when ClusterLink is enabled.

Following are the message bus components which we'll use while implementing it:
  1. Message Bus: Manages transfer of messages from message senders to message listeners.
  2. Destinations: Addresses or endpoints to which listeners register to receive messages.
  3. Listeners: Consume messages received at destinations. They receive all messages sent to their registered destinations.
  4. Senders: Invoke the Message Bus to send messages to destinations.
We have to follow the steps given below, to create a message bus in Liferay:

Step 1: First of all we need to create messaging-spring.xml in /src/META-INF of your plug-in portlet. If you don’t have a service builder in the portlet, then you won't be having this META-INF folder, in that case you have to create a dummy service for the same. Now we have to put the following contents in this file:


Step 2: Now we have to make entry of this file in spring config. To do so, we have to open the service.properties file and make the entry of this file in "spring.configs" property.

Step 3: What remains wow is to create a class which should process the messages. This class must inherit the class MessageListener and should also implement method receive. (Please help yourself with proper imports)


Step 4: All set, now use the following code invoke this listener from your code from action class, scheduler etc. from wherever you want.

Thanks for reading.

Ref: Liferay Message Bus

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 portal-ext.properties 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.