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
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
No comments:
Post a Comment