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);