And, so for 3.0: Move org.apache.logging.log4j.internal.DefaultLogBuilder to org.apache.logging.log4j.spi since it is the only place seems to be used from and make it package private unless I am misunderstanding the layout?
Gary On Mon, Dec 16, 2019 at 3:03 PM Gary Gregory <[email protected]> wrote: > I'll harp on one more thing :-( Why is LogBuilder called as such? It does > not "build()" a "Log", we do not even define a "Log". It does not build > anything right? It actually logs... oh well. Bummer for me that I like > discussing names of things ;-) > > Gary > > On Mon, Dec 16, 2019 at 2:57 PM Gary Gregory <[email protected]> > wrote: > >> Now that I see atInfo(), atWarn() and so on, for 3.0, I _expect_ to get >> rid of the 400+ methods in Logger that repeat the exact same args but with >> different method names (info(...), debug(...), ...) >> >> If we care a lot of about making conversion to 3.0 easier, then we can >> leave the old cruft in, but offer a new Logger interface that does not >> contain the old stuff. We or at least I've heard the complaint in the past >> on the size of Logger (Ctrl-space and boom! So many choices!), this would >> really clean things up (for my definition of "clean" of course :-) >> >> Gary >> >> On Mon, Dec 16, 2019 at 2:48 PM Gary Gregory <[email protected]> >> wrote: >> >>> >>> >>> On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers <[email protected]> >>> wrote: >>> >>>> >>>> >>>> > On Dec 16, 2019, at 11:13 AM, Gary Gregory <[email protected]> >>>> wrote: >>>> > >>>> > From the 10,000 ft level, within one app: >>>> > >>>> > - Log4j 2 configures itself by finding a log4j2.xml file. >>>> > - Log4j 3 configures itself by finding a log4j3.xml file. >>>> > - Both can co-exist happily >>>> > - The bridge exercise can be done separately. >>>> >>>> No, no, no. Nobody wants more than one logging implementation active. >>>> Nobody. And so far we haven’t talked about changing the logging >>>> configuration syntax, nor do I see any reason to do that. So there is no >>>> need for a log4j3.xml. >>>> >>>> If we go down that road you will just piss off users and have them >>>> switch to other logging choices. >>>> >>>> >>>> > >>>> > The APIs b/w Log4j 2 and 3 are already not binary compatible WRT to >>>> > appenders at least, I know I've removed deprecated methods, not sure >>>> about >>>> > the log4j-api module. >>>> >>>> There is a big difference between the API and implementation. While we >>>> should make every attempt to allow Plugins written for 2.x to continue to >>>> work against 3.x we can require that plugins may have to be modified to >>>> compile against 3.x. That is the route I have been taking with all the >>>> changes I have made, including the changes I made to the plugin system >>>> itself. Of course, we will need to verify that 2.x plugins actually run >>>> with 3.x and fix any bugs we find. >>>> >>>> >>>> > >>>> > IMO: A major version let's us break things and provide a better API, >>>> > otherwise, we can keep on the 2.x branch. >>>> >>>> Yes, we can improve the API, but code compiled against 2.x still needs >>>> to run against 3.x. While we can break things inside the implementation we >>>> should avoid breaking the API. Otherwise our users will hate us. You have >>>> to remember how much code there is out there that uses the API. If you >>>> make it incompatible you are just giving users a reason to use SLF4J. >>>> >>>> If you want an improved API you can create a new interface, but users >>>> probably won’t love that either. >>>> >>>> >>>> > >>>> > For example, this API and all like it should be gone from 3.0: >>>> > >>>> > org.apache.logging.log4j.Logger.debug(Marker, >>>> > org.apache.logging.log4j.util.Supplier<?>) >>>> > >>>> > and replaced with: >>>> > >>>> > org.apache.logging.log4j.Logger.debug(Marker, >>>> > java.util.function.Supplier<T><?>) >>>> >>>> Why? A user coding a Lambda doesn’t care what the underlying class is. >>>> Only people actually coding to that interface (nobody?) would care. >>>> >>>> >>>> > >>>> > Everywhere we have org.apache.logging.log4j.util.Supplier in 2.0, >>>> should be >>>> > replaced by java.util.function.Supplier in 3.0. >>>> >>>> -1 unless you can give me some benefit to doing that besides - “it is >>>> the standard Java interface”. >>>> >>>> >>>> > >>>> > In fact, we could (should IMO), now that we are on Java 8, in 2.14.0, >>>> add >>>> > java.util.function.Supplier version of all methods and _deprecate_ all >>>> > org.apache.logging.log4j.util.Supplier methods. >>>> >>>> Umm, I am doubtful you can do that. I’d be surprised if the compiler >>>> can figure out which one to use when it is compiling a lambda. >>>> >>>> > >>>> > We can also explore other kinds of logging APIs. One maybe goofy >>>> example >>>> > was my attempt a long time ago maybe even still in some branch of >>>> having >>>> > log methods on levels so you can say "Level.DEBUG.log(levellogger, >>>> ...)" >>>> > which I did to avoid the explosion of methods on Logger whenever you >>>> want >>>> > to add a new API (you need to duplicate it for debug, info, warn, and >>>> so >>>> > on.) >>>> >>>> We just added that in 2.13.0. Did you miss that? >>>> >>> >>> Oh, I see org.apache.logging.log4j.spi.AbstractLogger.atInfo()... >>> I certainly missed the proposal and discussion on the this ML, I must >>> have been asleep at the wheel, bummer for me. Because the API names... ugh >>> :-( What would have been wrong with simply naming the API by level name, >>> like info(). I don't see much precedent for "at" as a prefix. >>> >>> Gary >>> >>> >>>> >>>> Ralph >>>> >>>
