On Mon, Dec 16, 2019 at 2:48 PM Gary Gregory <garydgreg...@gmail.com> wrote:
> > > On Mon, Dec 16, 2019 at 1:36 PM Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> >> >> > On Dec 16, 2019, at 11:13 AM, Gary Gregory <garydgreg...@gmail.com> >> 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. >> > You don't get to choose. Some libs use JUL, some use Log4j, some cook up their own thing and that's fine as long as the write log files get written in the right places, as users expect. Just because Log4j is on the classpath does not mean that all logging must go through it. Gary > >> 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 >> >
