Hi Volkan, On Mon, Mar 14, 2022 at 9:23 AM Volkan Yazıcı <vol...@yazi.ci> wrote: > My preference would be the *lowest-value-comes-first* strategy for the > following reasons: > > - Natural ordering in Java (e.g., `Stream#sorted()`) yields the same > result > - This is how it works for Spring's `@Order` annotation
I like it, together with the current documentation that makes 3 reasons to keep the current order. However `org.apache.logging.log4j.core.config.Order` seems to suggest an inverse order. > I would appreciate it if you can align javadoc and manual with this PR too. It should be already aligned. > Mind explaining what do you mean by *"the provider's priority uses the > highest-value-wins strategy"*, please? Sorry, I was referring to the `org.apache.logging.log4j.spi.Provider` selection algorithm. Unless I am mistaken, `LogManager` chooses the provider with the highest numerical value: https://github.com/apache/logging-log4j2/blob/10460ec5200aa7eafb33b200f0f349a66e16c708/log4j-api/src/main/java/org/apache/logging/log4j/LogManager.java#L86 So if multiple Log4j 2.x API implementations are present, they are chosen in the order: 1. `log4j-jul` (priority 20) 2. `log4j-to-slf4j` (priority 15) 3. `log4j-core` (priority 10) Thinking about it, this seems like a bug. I don't recall the provider priority being documented anywhere, so maybe this can be also reversed in `release-2.x`. Piotr
