[logback-user] Standalone instance with multiple log4j setting

[Ceki Gülcü]

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