WAR file built Using Liferay Plugins SDK contains java source files

The standard Liferay SDK build process includes all java sources to the deployment units (war file).

As Liferay is Open Source, it makes sense to include the code also in the war, if someone just download the plugin war and installs it. This holds good for the plugins developed to be shared among the community. But it is not acceptable while building it for any enterprise project.

It is possible to override the war target in individual build.xml of the portlet or you could just replace the target with your own in the build-common-plugin.xml so it applies to all portlets in your SDK. Below is the snippet.

<target name="war" depends="compile">

<mkdir dir="${sdk.dir}/dist" />

<if>

<available file="tmp" />

<then>

<property name="docroot.dir" value="tmp" />

</then>

<else>

<property name="docroot.dir" value="docroot" />

</else>

</if>

<delete file="${plugin.file}" />

<antcall target="clean-portal-dependencies" />

<if>

<available file="docroot/WEB-INF/liferay-hook.xml.processed" />

<then>

<property name="liferay-hook.xml.excludes" value="WEB-INF/liferay-hook.xml*" />

</then>

<else>

<property name="liferay-hook.xml.excludes" value="" />

</else>

</if>

<if>

<contains string="${app.server.dir}" substring="glassfish" />

<then>

<zip

basedir="${docroot.dir}"

destfile="${plugin.file}"

excludes="**/META-INF/context.xml,${liferay-hook.xml.excludes},${plugins.war.excludes}, WEB-INF/src/**"

>

<zipfileset

dir="${docroot.dir}"

fullpath="WEB-INF/liferay-hook.xml"

includes="WEB-INF/liferay-hook.xml.processed"

/>

</zip>

</then>

<else>

<zip

basedir="${docroot.dir}"

destfile="${plugin.file}"

excludes="${liferay-hook.xml.excludes},${plugins.war.excludes}, WEB-INF/src/**"

>

<zipfileset

dir="${docroot.dir}"

fullpath="WEB-INF/liferay-hook.xml"

includes="WEB-INF/liferay-hook.xml.processed"

/>

</zip>

</else>

</if>

<if>

<and>

<equals arg1="${plugins.src.zip.enabled}" arg2="true" />

</and>

<then>

<zip destfile="${plugin.src.file}">

<zipfileset

dir="${docroot.dir}"

excludes="${liferay-hook.xml.excludes}"

prefix="${plugin.name}-src-${plugin.full.version}"

/>

<zipfileset

dir="${docroot.dir}"

fullpath="${plugin.name}-src-${plugin.full.version}/WEB-INF/liferay-hook.xml"

includes="WEB-INF/liferay-hook.xml.processed"

/>

</zip>

</then>

</if>

</target>

Adding Documents to liferay Document Library through API

While adding documents to documents library there are two ways of doing it using the liferay API,  DLFileEntryLocalServiceUtil or DLAppLocalServiceUtil

Difference between DLFileEntryLocalServiceUtil and DLAppLocalServiceUtil

DLFileEntry services and DLFolderEntry services are specifically for storing file and folder entries in liferay's database and are totally unaware of the new repository concept introduced in 6.1. The user-guide & this wiki explains how to add a new repository.

Where as DLApp (DLAppService & DLAppLocalService) services take into account these things i.e. to say that they take care of syncing documents between liferay database and other repositories, and not just store entries in Liferay database.

Adding documents to Documents Library

1. Get the File object (using input stream) of the file which is being inserting to the document library.

2. Get the FileInputStream 

InputStream inputStream = new FileInputStream( file );

3. Get the ThemeDisplay from the request. This is used for retrieving the user id and group id while adding the documents which is depicted in the further steps down.

ThemeDisplay themeDisplay = ( ThemeDisplay ) actionRequest.getAttribute( WebKeys.THEME_DISPLAY );

4. Get the Service Context object

ServiceContext serviceContext = ServiceContextFactory.getInstance( actionRequest );

5. Get the access folder in which the document would be placed.

Folder folder = DLAppLocalServiceUtil.getFolder( themeDisplay.getScopeGroupId(), 0, "<<Name of the folder>>" );

Here the first argument is the repository ID,  If the repository is a default Liferay repository, the repositoryId is the groupId or scopeGroupId. Otherwise, the repositoryId will correspond to values obtained from RepositoryLocalServiceUtil.

6. Now finally the inserting to the document library using DLAppLocalServiceUtil

FileEntry fileEntry = DLAppLocalServiceUtil.addFileEntry( themeDisplay.getUserId(), folder.getRepositoryId(), folder.getFolderId(), fileName,

contentType, fileName, fileName, "changeLog", inputStream, file.length(), serviceContext );

That is all we need to do, document is now inserted in the document library.

Defining custom Velocity Variables for Liferay Themes

There are number of predefined variables that can be accessed from with in the liferay theme. For elaborated list of those, below is the url

http://www.liferay.com/community/wiki/-/wiki/Main/Access+Objects+from+Velocity?_36_pageResourcePrimKey=2905717

Apart from those variables, if at all we end up needing a custom variable, which define a custom functionality/value as per the specific business need, we can define them in two places.

1. init_custom.vm. 

init.vm file, which is present in the liferay theme, contains all the liferay defined velocity variables. As a best practice, all the custom variables should be defined in the init_custom.vm file. 
This file allows you to override and define new Velocity variables.

#set($background_url = $theme_display.getThemeSetting('background-url'))

In the above example we are reading the background-url value provided by the user, while configuring the themes.

2. Setting the variables in request scope under attribute WebKeys.VM_VARIABLES

Create a hook, either Service Pre action or Login Post Action hook and inside your extended pre or post Action class, create a Map object with the key and value of the vm variables you want to insert, and then set that into the attribute under the key WebKeys.VM_VARIABLES. The variables added to the map are directly accessible in the Theme. This method provide more flexibility than the earlier one as there are no restrictions for defining the variables in this method.

Here is the code snippet for the same


Map< String, Object > vmVariables = ( Map< String, Object > ) request.getAttribute( WebKeys.VM_VARIABLES );

if ( vmVariables == null ) {         vmVariables = new HashMap< String, Object >();
}
vmVariables.put("someVariable", "someValue");

request.setAttribute( WebKeys.VM_VARIABLES, vmVariables );

Now the variable added to the Map is directly accessible from with in the velocity template file in the theme.

For example it can be directly accessible from portal_normal.vm as below

<a id="siteLogo" class="logo $logo_css_class" href="$someVariable" title="#language("go-to") $site_name"/>

Deploying the liferay war to non root context

There might be situations where you need to deploy liferay on to the different context than the default root("/") context.

One classic use case is - let us say you have a application that is deployed to the context "/app" and liferay reserves this context for json webservices. In this case you will have a context conflict thus making the liferay json ws not work properly.

For deploying liferay in non root context is two step process.

1. Add the property to portal-ext.properties
        portal-ctx="/whatevercontext"
2. Change the context path of liferay where it is deployed,  from root to whatevercontext context.

Customizing the Control Panel sections in liferay

Customizing the sections that are present in the control panel are flexible in liferay. You can control these sections from portal-ext.properties.

For customizing My Account, input a list of sections that will be included as part of the user form when updating a user in the My Account portlet.


#users.form.my.account.main=password,organizations,sites,user-groups,roles,categorization
#users.form.my.account.identification=addresses,phone-numbers,additional-email-addresses,websites,instant-messenger,social-network,sms,open-id
#users.form.my.account.miscellaneous=announcements,display-settings,comments,custom-fields


For customizing Users under Users and Organization, input a list of sections that will be included as part of the user form when updating a user.

#users.form.update.main=details,password,organizations,sites,user-groups,roles,personal-site,categorization
#users.form.update.identification=addresses,phone-numbers,additional-email-addresses,websites,instant-messenger,social-network,sms,open-id
#users.form.update.miscellaneous=announcements,display-settings,comments,custom-fields

Log4j Logging in Liferay 6.1 on Websphere Application Server

In order to have log4j logging we need to have the log4j.xml or lo4j.properties in the classpath so that log4j will pick this configuration file and start logging accordingly. Ofcourse this is one of the methods for configuring the log4j.

We had a situation where we were using a third party api and to my surprise, it has log4j.xml in its jar file. I know it is ridiculous but it does and we can't get rid of this jar. To make scenario more complicated, this is present in the shared library and loaded before any other portlet app is loaded, as the default class loading policy is "Parent First".

Given the above scenario, configuring the logging with log4j in Liferay 6.1 on WAS became bit tricky. We had two options here

Option 1:

Changing the class loading policy to "Parent Last" on the portlet application (using WAS admin console) should do the trick. But it leaves the hooks, if at all present in your application, to behave strangely and almost make them not to work as expected.  

Option 2:

Rename the lo4j.xml and load it explicitly using the Servlet Context Listener. To make it more modular, create a context param for the log4j config file name and send it as a argument. All this configuration has to go into web.xml

We leaned towards Option 2, thus avoiding the night mares with liferay hooks that would be introduced with Option 1

Dynamic Query

Liferay API provides means of accessing the liferay default entities via its liferay API. There would be situations where you need to access a entity with parameters, other than the methods provided by liferay. In which case, dynamic query will be a handy way. It is also a method in the liferay API where you can add the custom query to retrieve the entity that you require.

Here is the sample code

ClassLoader classLoader = PortalClassLoaderUtil.getClassLoader();
or if this service builder method is being called from external portlet better use 

ClassLoader classLoader = PortletClassLoaderUtil.getClassLoader( "<<portlet_id>>" );

DynamicQuery dynamicQuery = DynamicQueryFactoryUtil.forClass(

                           AssetCategoryProperty.class, classLoader).add(

                           PropertyFactoryUtil.forName("categoryId").eq(categoryId));

List<AssetCategoryProperty> liAssetCategoryProperty = AssetCategoryPropertyLocalServiceUtil

                           .dynamicQuery(dynamicQuery);

Here in the above example, I am trying to retrieve the properties that I define on the Asset Category. By default there is no method provided by liferay API (AssetCategoryPropertyLocalServiceUtil) to retrieve the AssetCategoryProperty using the category id. Hence Dynamic Query comes into picture.

SAML Portlet On Websphere 8.0

Deploying the saml-portlet plugin on the websphere throws exception (NullPointerException) resulting saml-portlet not deploying properly.

§

Websphere doesn't initialize filters (InvokeFilter) on startup, but rather, on the first call. This is different from Tomcat, which initializes during the application startup. The root of the issue (in Websphere) is that InvokerFilter is not yet initialized and set into the context at the time when used in HookHotDeployListener, which is why there is a null context and throws NPE.

http://www-01.ibm.com/support/docview.wss?uid=swg1PM62909

So the workaround is to set the following custom properties in the web container:

com.ibm.ws.webcontainer.initFilterBeforeInitServlet = true
com.ibm.ws.webcontainer.invokeFilterInitAtStartup = true

To specify web container custom properties in Websphere:

1. In the administrative console click Servers > Server Types > WebSphere application servers > server_name > Web Container Settings > Web container .
2. Under Additional Properties select Custom Properties.
3. On the Custom Properties page, click New.
4. On the settings page, enter the name of the custom property that you want to configure in the Name field and the value that you want to set it to in the Value field.
5. Click Apply or OK.
6. Click Save on the console task bar to save your configuration changes.
7. Restart the server.

Once these configurations are made saml-portlet deploys correctly and runs perfect.

Setting/Getting the Custom Field (Expandos) values

At times during the development, we might end up defining the custom fields on the liferay default entities(User, Organization etc.,) in order to squeeze in the custom attributes that the project requirements dictates. Once they are defined (in the control panel), we can use the below methods to retrieve them

Method 1:

First get the entity here in our example User by using one of the relevant API methods

User user = UserLocalServiceUtil.getUserById(userid);

For setting the value

user.getExpandoBridge().setAttribute(IConstants.EXPANDO_USER_JOB_DESCRIPTION, "some desc" );

For retrieving the value


user.getExpandoBridge().getAttribute(IConstants.EXPANDO_USER_JOB_DESCRIPTION);

Method 2:

Some times due to some security restrictions (from where you access this method) the above method doesn't work.In which case we end up using the Expoandos API to set and get the values from the custom attributes

User user = UserLocalServiceUtil.getUserById(userid);

ExpandoTable table = ExpandoTableLocalServiceUtil.getTable(user.etCompanyId(),User.class.getName(), ExpandoTableConstants.DEFAULT_TABLE_NAME);

ExpandoColumn column = ExpandoColumnLocalServiceUtil.getColumn(user.getCompanyId(),User.class.getName(), table.getName(), "Custom Field Key" );

String strSsouserScreenNamePrefix =  ExpandoValueLocalServiceUtil.getData(user.getCompanyId(),User.class.getName(), table.getName(), column.getName(), user.getUserId(), StringPool.BLANK);