> 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.
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?
Ralph
