You don't duplicate any logging config. You can use both slf4j-api and log4j-api with either logback or log4j2.
On 4 September 2017 at 00:08, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > If you ignore the container point - which for me is already blocking - you > have 2 issues with migratong to log4j2: > > 1. it is not mainstream compared to slf4j for instance so means once again > duplicating logging configs in user apps > 2. what would give stability to jcs users? Commons logging was targetting > this goal then it has been sl4j and now log4j2? Means each time you upgrade > you switch the lib which sounds horrible for a commons project. > > Side note on tomee isolating jcs: compared to other servers tomee doesnt do > it to let users inherit from all features and integrate with the libs > naturally. It has the drawback you mention bit the advantage to be able to > use the full ecosystem so will likely not change soon. > > Le 4 sept. 2017 02:30, "Ralph Goers" <ralph.go...@dslextreme.com> a écrit > : > > > 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 > > > > > -- Matt Sicker <boa...@gmail.com>
