We have one j2ee application with only one ear. We have the log4j.jar at ear level under lib directory and then we set up LD_LIBRARY_PATH (through WebSphere - which is done at server scope) to point to that folder so that our utility jar and war can pick log4j.jar and log4j.properties from ear/lib. We are running this application on websphere running on Linux box.
With this configuration, it was running fine, creating our custom log files at specified location in log4j.properties.
Now, I have created 2 instances of server on the same machine - one for development, one for testing. I installed the same ear on the newly created server instance, changed log4j.properties to write log files in different directory tree. So now, I have 2 instances of websphere servers running on same machine, running basically same application (with it's own copy of everything off course).
But, I see that the logs that should be have been created by this 2nd application are still being written in the log file that was initially created by 1st instance. The 2nd application never created it's own log files under the new directory specified in it's own log4j.properties.
As I understand, 2 different instances of server have 2 seperate jvms, also they have their own copy of log4j. Hence, even if log4j is singleton, that shouldn't matter and it should have been totally unaware about the 1st application and hence 1st log4j. Thus the 2nd application should have created it's own log files and written logs there.
Can anyone shed any light on what I may be missing?
You may need to bounce the app in 2nd instance after changing the Log4j.properties (if this is EAR scope) else you may need to bounce the server 2nd instance. This usually happens if you change the properties after installation and startup of app.
Joined: Apr 25, 2005
Originally posted by sridhar: You may need to bounce the app in 2nd instance after changing the Log4j.properties (if this is EAR scope) else you may need to bounce the server 2nd instance. This usually happens if you change the properties after installation and startup of app.
What do you mean by 'bounce' application or server. You are right on the money about changing log4j.properties after installation. That's what I was doing: both ears have same log4j.properties - hence after I install 2nd ear, I go in, change log4j.properties for that ear and restart the server2 - meaning I Do restart server 2 (I guess that's what you mean by bounce).
I think next thing to try will be: 1. install ear on server2 2. stop server 2 3. go and change log4j.properties 4. restart server 2, hence the application and see where the logs fall