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 >>> >>
