2017-09-05 15:33 GMT+02:00 Ralph Goers <ralph.go...@dslextreme.com>: > > > On Sep 5, 2017, at 12:11 AM, Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > > 2017-09-05 9:01 GMT+02:00 Apache <ralph.go...@dslextreme.com <mailto: > 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. > > > > > I see your point. I guess we never built a bridge from the Log4j 2 API to > JUL simply because we couldn’t imagine anyone would want to use it :-) As I > said, by choosing jul you have gone with the worst option. You would have > been better off creating your own API. > > I think you will see in my original email I said that containers are a > special case - either they should hide all the third party dependencies > they use or they should use their own logging abstraction. It sounds like > TomEE doesn’t do either of these. >
It is more complicated, tomee does for the code it owns, as well as cxf, owb, .... but the most consistent API is JUL for all of them (most of them even just subclass JUL to allow extension). It looks doable to be fast with JUL since you can override Logger completely so I'm tempted to say that in term of API not that impacting until you use very advanced signature (which is not the case of container stacks in general). > > If you need an adapter from the Log4j 2 API to a TomEE implementation just > create a Jira issue at Log4j 2. I am sure we would be happy to provide it. > I think it must go the other way: log4j2 must push projects to move otherwise projects will be happy with X -> log4j2 bridges, no? > > Ralph > >
