The log4j-api to JUL bridge would be for users who have a JUL logging config already that don't want to change, but do want all code to log to the same location.
On 5 September 2017 at 08:45, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > 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 > > > > > -- Matt Sicker <boa...@gmail.com>
