On Mon, 8 Sep 2003, Remy Maucherat wrote:
Howdy, Seems like a good idea: the struts/log4j case is very common from what I've seen, and moreover I think it's a best-of-breed/best-practice configuration that we want to support seamlessly.
That's the idea. Now that I got it to run well, I like commons-logging :)
On that topic, is there a reason that Tomcat 5.0.x still uses commons-logging-api.jar instead of commons-logging.jar? If you're putting this jar in common/lib, you'd avoid the need for webapps to have to include commons-logging.jar themselves in order to use the default functionality.
Craig, you're funny :-D The reason is that any setup other than the current one doesn't work ;-)
Facts:
- The c-l API must be in the system CL
- the implementation of a logger must reside in the same CL as the logger (ie, if there's log4j somewhere, commons-logging.jar must be next to it)
Of course, this is caused by the fact that internal components use c-l, and the webapp CL don't delegate (if there's a special case for c-l, it works, except if the webapp is privileged; and anyway, I wanted to remove the special case for c-l and have the most elegant solution).
Remy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
