At 10:53 AM 3/23/2004 +0100, you wrote:
Ceki, if you are reading this, why the change to the interface? You had been pretty opposed to this before.
Also, why the change to the JNDI lookup in ContextJNDISelector to to be "java:comp/env/log4j/context-name" instead of "java:comp/env/log4j/logging-context" as it was in the sandbox? I realize that the sandbox is not official code, but it makes moving to Log4j-1.3 more difficult since anyone using the old one will have it configured to use "logging-context" (including me, of course). I think the javadoc still refers to "logging-context" not "context-name" in one spot, although the example provided says "context-name". If there is no real good reason to change the name, can it move back to "logging-context"? The new autoconfiguration looks interesting. Maybe my advice to Vance about configuration not belonging in the repository selector was premature. I'll have to try it sometime here. In any case, could you detail your reasons for the change to the RepositorySelector interface?
If the repository selector can be set dynamically from a configuration directive, then there must be a way for the component configuring the repository selector to configure and set the default repository, hence the new method.
Hmm... I just provide a default configuration file in the server. For instance, CATALINA_HOME/common/classes/log4j.xml with log4j.jar in common/lib. Tomcat uses the default repository and later, when my webapp is initialized, the repository selector is set (if it hadn't been already). Seems to work fine for me. I guess I'm wondering why a solution was needed for a problem that doesn't seem to exist? I'm probably just missing something.
Moreover, the exact implementation of the default repository does not need to depend on the implementation of the repository selector.
Maybe not, but what pressing need do you see for this? Like I said above, things work fine for me as is in 1.2.8.
As for backward compatibility, it is not guaranteed for code in the sandbox.
Sure, but change for change sake is also unnecessary. Did you "need" to change the name from "logj4/logging-context" to "log4j/context-name"? If there is a good reason to change it, fine. If it is arbitrary, then why not keep the same name? It doesn't hurt you and it helps me and anyone else who has been using that name in applications. It's an indifferent/win (logging-context) -vs- indifferent/lose situation (context-name).
One comment on ContextJNDISelector. If I use InitShutdownController to set the repository selector and then do configuration, you will ultimately reset my configuration with the first call to getLoggerRepository(). First you attempt to use a URL to the file defined in JNDI under the name "java:comp/env/log4j/configuration-resource". If that is null, you attempt to load off the classloader. The latter step is problematic since I might not have a config file in the classpath, but there might be one in the server's classpath which isn't my own. In fact, I usually keep mine in WEB-INF/config and let InitContextListener initialize it. This will stomp on my configuration, very likely with the wrong config file. Furthermore, in the case that no config file is found, you the print "Could not find resources to perform automatic configuration.". So, my configuration will either be reset or I will get an annoying message even though I've already configured my logger repository. Am I just tired and misinterpreting what ContextJNDISelector does, or is this behavior not quite right?
Jake
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
