2017-09-05 9:01 GMT+02:00 Apache <ralph.go...@dslextreme.com>: > > > > Sent from my iPad > > On Sep 4, 2017, at 10:03 PM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > > Le 5 sept. 2017 05:40, "Ralph Goers" <ralph.go...@dslextreme.com> a > écrit : > > > > > >> On Sep 4, 2017, at 2:24 PM, Romain Manni-Bucau <rmannibu...@gmail.com> > > wrote: > >> > >> Le 4 sept. 2017 20:44, "Matt Sicker" <boa...@gmail.com> a écrit : > >> > >> You don't duplicate any logging config. You can use both slf4j-api and > >> log4j-api with either logback or log4j2. > >> > >> > >> Except you dont always have the choice with 2 apis. It also messes up > >> logging lifecycle and setup which needs 2 integrations in the > environment. > >> Whatever reason you use it is not free to switch and even if log4j2 is > >> awesome, it is far to be a first citizen api for a common library used > in > > a > >> lot of contexts IMHO. > > > > Now you have me curious about your last sentence. In you opinion, what is > > keeping Log4j2 from being a first citizen api for a common library? You > > didn’t mention SLF4J in that sentence so I am assuming you consider it to > > be one. Why? > > > > > > Purely usages as an api. Once again the fact I'm very cautious moving to > > log4j2 api is not about the quality of log4j2. Take most of asf project > > stacks and I guess slf4j, jul or even commons logging will be more used > > than log4j2 as an API. Side question: wonder if we can extract this stat > > through asf infra? > > > > I hear the "if noone starts" side of the issue but it must be more global > > than just one lib by lib (a bit like when tomee needs to support one more > > java version and upgrades asm in openjpa, cxf, tomee, owb, ... at once). > > > > You can look at the download stats from repository.apache.org. You will > see there are more downloads of the API than Log4J-core, but to be honest I > have no idea what that means. I am just happy that the trend keeps going up. > > What does it really matter if it used more (or less) as an API? What > matters most is how well it works for you and your users. In addition, if > you look at the Github and Jira stats you will see that Log4J has been far > more active over the last few years, so you are much more likely to get > better support. >
I think we agree on the user first point but not on what it means. By itself log4j2 is awesome but in a container it just leads to issue until the whole stack is log4j2. Just take tomee 7 webprofile (which is 1/3 of the full distribution and not that far from a user app in term of stack): - cxf - tomcat - [beanutils] - [collections] - [dbcp2] - [digester] - [lang3] - [pool2] - geronimo-javamail - geronimo-transaction - hsqldb - johnzon - myfaces - openejb/tomee - openwebbeans - quartz - xbean How many use log4j2-api? None. All have potential bridges based on JUL, slf4j or [logging] but none use log4j2. Now assume you make log4j2 an api of jcs which fall into tomee+, then we need to add log4j2 api with a jul implementation by defaut or change the logging stack which is likely not an option and would lead to inconsistencies with tomcat (would break tomee philosophy). So we are back to my last point: either somebody has enough time to PR and get it merged on all projects (if "limited" to asf it would already enable it I think) at ~once and then log4j2 could be seen as an API and good replacement of slf4j/[logging] or this fight will always block at integration level. Once again it is not about the log4j2 quality but more the overall ecosystem. > > Ralph > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
