Although I am a big fan of Log4j 2, there are use cases where more thought needs to be given then just adopting it, SLF4J, JUL, etc.
The problem comes into play in in frameworks like Tomcat, TomEE or JBoss AS. These frameworks need to perform logging but whatever they use has to be able to meet a few types of users: 1. Users that have multiple apps running in the container and want them all to use the same configuration and log to the same files. 2. Users that have multiple apps running in the container and want them to have separate logging and log to different files. 3. Users that have multiple apps running in the container and want all the container logs and application logs to use the same configuration. In addition, we know that various libraries and frameworks have chosen to use different logging frameworks. Usually, users want all of these consolidated so that they can use a single configuration for the application. This is easily doable except when the frameworks use java.util.logging AND the container also uses java.util.logging. Due to the way java.util.logging works the logging framework jars have to be placed in the class path of the container which makes it impossible to achieve item 2 above. Similarly, if the container uses ANY of the common logging libraries, and they are exposed on the application’s class path then users are required to use the logging libraries provided by the container and cannot use their own versions. That statement made in one of the emails that if JCS switches logging frameworks it would mean it would have to be dropped from TomEE since TomEE will be using JUL. This is a prime example of what I mentioned in the previous paragraph. The correct solution here is to get TomEE’s use of JCS out of the user’s application class path. Unfortunately, that isn’t trivial. However, containers are a special case. Most frameworks just use a logging framework and aren’t creating their own class loaders. In that case my advice is always “NEVER use java.util.logging”. First, its performance is terrible and second it is extremely difficult to use it as an API and direct the calls to another framework. I have been told the implementers of jul spoke with Ceki before implementing it but they must not have asked him the correct questions to come up with a design that is so bad. So just saying that Log4j 2 or SLF4J (or whatever else) should always be used isn’t necessarily correct. In the case of Tomcat or TomEE, if they cannot completely hide the logging framework from applications then it needs to use its own custom facade that any logging framework can implement (and NOT use JUL). What they have done with JULI was on the right track but still uses the java.util.logging design, which makes it very difficult for users to achieve item 3 above. As far as I can tell JCS is a general purpose caching system meant to be used as a library within an application. For that use case, in my opinion using the Log4j 2 API is a much better choice than using Commons Logging. Ralph > On Sep 3, 2017, at 2:09 PM, Matt Sicker <boa...@gmail.com> wrote: > > As an end user of libraries, I much prefer when they stick to using > log4j-api or slf4j-api instead of some annoying library-specific facade > which requires even more configuration to set up in the end. As long as I > can pull in log4j-api, log4j-core, and log4j-slf4j-impl, everything "just > works" essentially across all my libraries and in house code. I understand > that some libraries are old and stuck to commons-logging as it was the main > facade at the time (e.g., in Spring Framework), but chances are that > nowadays, at least one or more of your libraries are going to bring in > log4j-api or slf4j-api anyways. > > On 3 September 2017 at 14:22, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > >> Had a test using cdi integration but moving the level test reduced >> execution time from ~1.4 to 1.25 (normalized numbers). It was ror millions >> of calls but still worth it IMO. Log impl was indeed jul ;). >> >> >> >> Le 3 sept. 2017 20:16, "Thomas Vandahl" <t...@apache.org> a écrit : >> >> On 03.09.17 20:11, Romain Manni-Bucau wrote: >>> On the perf thing: isXXXEnabled can be costly by itself - see my last >>> commit. >> >> Could you please provide some numbers to this claim? >> >> Bye, Thomas. >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > > -- > Matt Sicker <boa...@gmail.com> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
