I would not be in favor of this change. Providers have been designed since day one that highest wins and it is documented - https://logging.apache.org/log4j/2.x/manual/extending.html#LoggerContextFactory <https://logging.apache.org/log4j/2.x/manual/extending.html#LoggerContextFactory>.
The fact that the user was surprised may be true, but the ordering was intentional. If you include log4j-to-slf4j it means you want to log to SLF4J. In that case log4j-core shouldn’t even be present. Ralph > On Mar 14, 2022, at 4:37 AM, Piotr P. Karwasz <[email protected]> wrote: > > On Mon, Mar 14, 2022 at 10:54 AM Volkan Yazıcı <[email protected]> wrote: >> Regarding your remark about providers... `Provider#getPriority()` has the >> following javadoc: *"Gets the priority (natural ordering) of this Provider"*, >> hence I would have expected it to work the same lowest-comes-first way, but >> apparently not – relying on your assessment here. I am also inclined to >> align them with the lowest-comes-first strategy, though this might have a >> bigger impact if there are 3rd party providers out there in the wild. Maybe >> others can weigh in here? > > I can provide some additional evidence supporting the necessity to > invert the order. At least one user on Stack Overflow was surprised > that after adding `log4j-core` to his project, the loggers are still > of type `org.apache.logging.slf4j.SLF4JLogger`: > > https://stackoverflow.com/q/70487959/11748454 > > Piotr
