2011/8/7 Mark Thomas <ma...@apache.org>: > On 07/08/2011 09:31, Jochen Wiedmann wrote: >> On Wed, Aug 3, 2011 at 3:02 PM, Gary Gregory <garydgreg...@gmail.com> wrote: >> >>> Or maybe Log4j 2 could replace [logging]. >> >> If we really have to reconsider this stuff, then I'd propose to >> >> a) Use java.util.logging, because it doesn't require any additional >> dependencies and is guaranteed to work anywhere. >> b) Carefully document how to bridge jul to log4j, because that's >> exactly what's required in almost any application container I am aware >> of. (The exception being Tomcat, which uses jul anyways.) >> c) If the slf4j fans insist, add similar documentation for bridging >> jul to slf4j. > > +1. I like this plan. > > As an aside, Tomcat doesn't use jul, it uses JULI which is a modified > commons logging implementation hard coded to output to jul by default > with an alternative Jar that is hard-coded for log4j. Why the > complexity? jul is not class loader aware which is a problem as soon as > web applications start declaring loggers with the same name. > > Mark
Regarding Tomcat, I want to correct Mark. Tomcat JULI != commons-logging. It is just that two components are packed in the same jar. (E.g. in Tomcat 5.5 they were separate). Tomcat logging (the "bin/tomcat-juli.jar:" file) contains the following: 1. Tomcat JULI which are additional components to java.util.logging. There are two main components: a) a custom implementation of java.util.logging.LogManager that is classloader-aware, allows to have separate logging configuration per webapp, and also to have more rich configurations than the default LogManager b) a custom FileHandler, that is better suited to our needs than the standard one. Tomcat JULI is enabled by setting certain java properties on the command line. 2. A copy of commons-logging renamed to a different package to avoid conflicts with webapp-provided copies of the library. The "tomcat-juli.jar:" can come in two flavors. Default one: The default one uses stripped down copy of commons-logging that has its discovery process removed and is hardcoded to use java.util.logging. Extras one: This includes full copy of commons-logging. It is *not* hard-coded for log4j. It is just that its discovery process is kept intact, so it can choose whatever logging framework it finds. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
