Okay, then we have consensus for changing the property source priority field handling to lowest-comes-first strategy. I recommend landing this feature in 2.18.0 rather than 2.17.3 or something, since this is potentially a breaking change of a not working feature.
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? On Mon, Mar 14, 2022 at 10:38 AM Piotr P. Karwasz <piotr.karw...@gmail.com> wrote: > 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 >
