Log4j problem in Websphere

[Vijay Chandran]

Dear Friends,

I have 3 EAR applications deployed in Websphere Application Server 6.1. All EAR files contian a WAR file inside it. I have specified the log4j.properties file inside the WEB-INF/classes folder in all the 3 applications. The log files have different path for all the 3 applications. For Example:

Following is the log file path mentioned in the log4j.properties file for all the 3 EAR applications:

EAR application 1: log4j.appender.log.File=C:/EAROne/log/EAROne.log
EAR application 2: log4j.appender.log.File=C:/EARTwo/log/EARTwo.log
EAR application 3: log4j.appender.log.File=C:/EARThree/log/EARThree.log

The problem is, if i execute any EAR application. all the logs are written in the same log file. Suppose if i execute application EAROne, the logs generated from the application are written in the EAROne.log. Similarly, if i execute applications EARTwo and EARThree, the logs generated from those applications are also written in the same EAROne.log file.

How to make the applications write their respective logs in their own log files according to the log file paths mentioned in their respective log4j.properties file?

Thanks in Advance,
Vijay

[Paul Clapham]

You didn't say where you put the log4j.jar file, and that is probably what is wrong.

[Vijay Chandran]

Hi Paul,

I've put the log4j.jar file in the WEB-INF/lib folder.

Thank you very much for the reply.

How the problem can be resolved?

Kindly help

Regards,
Vijay

[Duc Vo]

It seems they are sharing the same log4j library.

(1) What is the settings for class loader of each EAR and of the virtual server on which you deployed these EARs?
(2) Do you have any other log4j.jar in the server classpath?

[Vijay Chandran]

Hi,

Thanks for the reply.

(1)How to check the class loader settings in websphere application server 6.1?

(2) I have put all the log4j.jar in the respectiver EAR application's WEB-INF/lib folder. So each EAR file has its own log4j.jar file.
There is a log4j.jar in the C:\Program Files\IBM\WebSphere\AppServer\lib folder. The version of log4j.jar is 1.2.8

Kindly help.

Regards,
Vijay

[Duc Vo]

Vijay Chandran wrote:
(1)How to check the class loader settings in websphere application server 6.1?

Open Administrative Console -> servers -> application servers -> server1 (or the name of your server)
In the general properties section, make sure "Classloader policy" is multiple and "Class loading mode" is parent last.

Vijay Chandran wrote:
(2) I have put all the log4j.jar in the respectiver EAR application's WEB-INF/lib folder. So each EAR file has its own log4j.jar file.
There is a log4j.jar in the C:\Program Files\IBM\WebSphere\AppServer\lib folder. The version of log4j.jar is 1.2.8

Yes, it is the problem. The above settings can't fix it, you may want to try to remove this log4j.jar as well (be careful though since the server may already be configured to use log4j).

Hope it help.

[Vijay Chandran]

Dear friend,

Sorry for the late reply. I was not feeling well for the past 4 days.

The suggestion you provided worked and now logging is happening perfectly.

Thank you very much,
Vijay

[siva kumarl]

Hi Vijay Chandran,

I am also facing the same problem for wiriting log in Websphere 7.0 server, and tried all the above metioned settings but it is not working. Could you please let me know the changes you have made.

Thanks in Advance,
Siva Kumar.

[Yogesh Gandhi]

I do not know if my suggestion here would exactly match with the question being asked, but my problem looks similar.

My problem was that logs were not being written to log file specified in log4j.properties. I was using websphere which had several applications deployed.

Class loading policy in websphere console was Multiple and parent last, as mentioned above. (i cross-checked).

I had no clue, what is going wrong and why logs are not getting generated.

At last, I made a struts-web-app as given on the link : https://www.javawebtutor.com/articles/maven/maven_struts_example.php

I added log4j-1.2.8.jar to it and I added the code in the else block before going to success.jsp

public class LoginAction extends Action {
	static Logger logger = Logger.getLogger(LoginAction.class);
	@Override
	public ActionForward execute(ActionMapping mapping, ActionForm form,
			HttpServletRequest request, HttpServletResponse response)
			throws Exception {
		LoginForm loginForm = (LoginForm) form;

		if (loginForm.getUserName() == null || loginForm.getPassword() == null
				|| !loginForm.getUserName().equalsIgnoreCase("Mukesh")
				|| !loginForm.getPassword().equals("kumar")) {
			return mapping.findForward("failure");
		} 
		else
		{
			String log4jConfigFile = System.getProperty("user.dir") + File.separator + "log4j.properties";
			HttpSession session=request.getSession();
			session.setAttribute("location",  log4jConfigFile);
		    PropertyConfigurator.configure(log4jConfigFile);
		    logger.debug("this is a debug log message");
		    logger.info("this is a information log message");
		    logger.warn("this is a warning log message");
			return mapping.findForward("success");
		}
	}

}

and in success.jsp, I just printed the path from where log4j.properties was being picked up.

What I saw after a while was that my logs of POC project was being printed, and ALSO my other app (which was actually having problem), its logs were also getting printed in the same log file (of POC project).

From this behavior I can only say that may be the instance of the logger is singleton for a websphere instance. I am not very sure of this, but the behavior seems like that only.

May be my problem was that some other log4j settings were overwriting my instance of the actual application.

[Yogesh Gandhi]

Yogesh Gandhi wrote:I do not know if my suggestion here would exactly match with the question being asked, but my problem looks similar.

My problem was that logs were not being written to log file specified in log4j.properties. I was using websphere which had several applications deployed.

Class loading policy in websphere console was Multiple and parent last, as mentioned above. (i cross-checked).

I had no clue, what is going wrong and why logs are not getting generated.

At last, I made a struts-web-app as given on the link : https://www.javawebtutor.com/articles/maven/maven_struts_example.php

I added log4j-1.2.8.jar to it and I added the code in the else block before going to success.jsp

public class LoginAction extends Action {
	static Logger logger = Logger.getLogger(LoginAction.class);
	@Override
	public ActionForward execute(ActionMapping mapping, ActionForm form,
			HttpServletRequest request, HttpServletResponse response)
			throws Exception {
		LoginForm loginForm = (LoginForm) form;

		if (loginForm.getUserName() == null || loginForm.getPassword() == null
				|| !loginForm.getUserName().equalsIgnoreCase("Mukesh")
				|| !loginForm.getPassword().equals("kumar")) {
			return mapping.findForward("failure");
		} 
		else
		{
			String log4jConfigFile = System.getProperty("user.dir") + File.separator + "log4j.properties";
			HttpSession session=request.getSession();
			session.setAttribute("location",  log4jConfigFile);
		    PropertyConfigurator.configure(log4jConfigFile);
		    logger.debug("this is a debug log message");
		    logger.info("this is a information log message");
		    logger.warn("this is a warning log message");
			return mapping.findForward("success");
		}
	}

}

and in success.jsp, I just printed the path from where log4j.properties was being picked up.

What I saw after a while was that my logs of POC project was being printed, and ALSO my other app (which was actually having problem), its logs were also getting printed in the same log file (of POC project).

From this behavior I can only say that may be the instance of the logger is singleton for a websphere instance. I am not very sure of this, but the behavior seems like that only.

May be my problem was that some other log4j settings were overwriting my instance of the actual application.

Today again the logs stopped printing in the new file... I again hit my success page  (which instantiates the logger ) and again the logs started printing.