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