At 10:24 PM 11/29/2004, Shapira, Yoav wrote:
Hi,
Any JNDI implementation would support InitialContext creation once it's initialized. But that's where the problem is. If the JNDI implementation itself needs log4j as part of its bootstrapping, we have a chicken-and-egg problem, and this test is not so good.
The test would be really bad because a single failure would force the ContextJNDISelectors to skip JNDI lookups for the rest of the JVM's life. Yoav, has just shown that such failures will certainly happen during the initialization phases of the Application Server.
For example in Tomcat, there are many logging statements made before the JNDI classes are initialized.
Roger that.
There are also corner cases for embedded servers (Tomcat and others), where the embedding application or the server itself might log before setting up JNDI.
So this test is iffy as it is right now. I can't say it's 100% universally correct. So it's a good thing the JNDI selector isn't the default. If someone specifies it as the default via the system property, they hopefully also ensure that JNDI subsystem is initialized.
Logging with ContextJNDISelector before JNDI is set up would not be a problem. The getInitialContext call would fail, and ContextJNDISelector would fallback on the default repository.
The problem is with the 'jndiAvailable' test
if(jndiAvailable) {
try {
ctx = JNDIUtil.getInitialContext();
} catch(NamingException ne) {
// a single failure in JNDIUtil.getInitialContext() will
// jndi lookups for good
jndiAvailable = false;
}We are just discussint it. It is not code committed in CVS.
Fantastic team work btw. :-)
Yoav Shapira http://www.yoavshapira.com
-- Ceki G�lc�
The complete log4j manual: http://qos.ch/eclm
Professional log4j support: http://qos.ch/log4jSupport
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
