On 01/04/2010 12:41 PM, WM YEOH wrote:

Hi Ceki,

Thank you for the guidance.

I think I better start all over again what was the actual problem to give you a better picture.

I am currently upgrading the sun one apps server from 7.1 to 9.1 (in UNIX platform), common-logging.jar, jakarta-log4j-1.2.6.jar and log4j-1.2.15.jar are currently specified in the server classpath. The logging problem occurred after upgraded to 9.1.

You should not have both jakarta-log4j-1.2.6.jar and log4j-1.2.15.jar on the server's class path. Pick one and only one.

I have an EAR file containing few jars (EJB involved) and a war file deploying in a standalone instance. I have another war file deployed within the same instance, meaning there are 2 apps running in one instance. When the instance startup, there are suppose to have 2 log files, for instance A.log and B.log. However, all the loggers only written in a single log, take A.log as an example. Both apps have their own initServlet to load the log4j configuration files.

I need some answers from you in order to clear my doubts,

- is logback my only solution?

No, logback is not your only solution. You could change the problem setting by using non-static logger references in your EJB classes. With the simplified problem you could stick with log4j. Having said that logback is the only platform that deals with the logging separation problem for shared classes with static loggers. Given that the rest of your post is logback related, I posted my full answer on the logback-user mailing list. If you wish to pursue the logback-based solution, then please continue the discussion there.

- can I used log4j-1.2.15 instead of slf4j-api-1.5.11?

You could either migrate your source code from log4j to slf4j with the slf4j-migrator (http://slf4j.org/migrator.html) or replace log4j.jar with log4j-over-slf4j as described in http://slf4j.org/legacy.html#log4j-over-slf4j.

- I am not too sure how logback.xml is been read, initServlet triggered to lookup the xml file or no sevlet needed only specified in web.xml?

Once installed ContextJNDISelector will determine whether the current logger context has been initialized and if not will read in the configuration as appropriate for the current context. The current context value is read from JNDI according to the "logback/context-name" env-entry you put in your web-app's web.xml file. This is described in http://logback.qos.ch/manual/loggingSeparation.html.

- what should be the value for<env-entry-value>, just the xml file name or should I include the path as well like /WEB-INF/classes/xml/A1.xml

Good question. The value of "logback/configuration-resource" env-entry is looked up as a *resource*. So if you place A1.xml under the /WEB-INF/classes/xml/ folder, you would need to specify the resource name "xml/A1.xml".

- by looking at the logback-starwars project, it looks very simple. And I assume there neither to add -Dlogback.ContextSelector=JNDI nor Dlogback.ContextSelector=myPackage.myContextSelector in system property?

If you wish to install the ContextJNDISelector, just set the "logback.ContextSelector" system property to "JNDI".

- is "myPackage.myContextSelector" means custom context selector written by me?

Yes.

Appreciate if you can help me to understand more about the logback concept and how can I solve the problem. Hope to hear from you soon.

Thank you.

You are welcome. -- Ceki