Thanks for the clarification. I will try to enumerate all the cases below: *[Below, 1, 2, and B denote Log4j 1, Log4j 2, and log4j-1.2-api, respectively.]*
*1/2/B:* failure, both 1 and B cannot be present (equivalent to #1 in your enumeration) *1/2/-:* 2 should detect `log4j.configuration`, yet due to the absence of B, discard it; a warning is not necessary since 1 is present (equivalent to #2 in your enumeration) *1/-/B:* 1 should do all the work *1/-/-:* 1 should do all the work *-/2/B:* 2 should detect `log4j.configuration` and employ it (equivalent to #3 in your enumeration) *-/2/-:* 2 should detect `log4j.configuration`, yet due to the absence of B, warn & discard it (equivalent to #4 in your enumeration) *-/-/B:* user doesn't know what he/she is doing *-/-/-:* recess for all I think we can test against all these cases using dedicated maven-surefire-plugin configurations where we exclude either 1, 2, and/or B as needed. Regarding Carter's *"when interesting plugin/webapp classloaders are used"* remark... I will act like I haven't read that. 😅 On Wed, Dec 22, 2021 at 6:13 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > > On Dec 22, 2021, at 9:20 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > > > Ralph, mind elaborating a bit more on what the exact problem is, please? > > `log4j.configuration` gets detected, log4j-1.2-api (provided by Log4j 2) > > kicks in, and tries to load the Log4j 1 configuration. This sounds okay > to > > me. I guess it gets messed up when an application uses both Log4j 1 and > 2, > > right? > > > Yes, if log4j 1.x is on the classpath they both think the system property > is meant for them. There are a few scenarios: > 1. Log4j 1.x and log4j-1.2-api are both present. This is an error as you > can’t have both the legacy implementation and the compatibility bridge > present at the same time. > 2. Log4j-1.x is present and log4j-1.2-api is not present. Log4j will look > for a factory for Log4j 1.x. It won’t find one and Log4j 2 will fail to > configure. > 3. Log4j 1.x is not present and log4j-1.2-api is present. Log4j will look > for a factory for Log4j 1.x and find it in log4j-1.2-api. > 4. Neither Log4j 1.x or Log4j-1.2-api are present. ConfigurationFactory > won’t find a factory and will return null. > > It seems the logic here needs to be changed so that if it can’t find a > Log4j 1.x configuration that it should continue looking for a Log4j 2 > configuration. I guess having it use the Log4j 1.x property name isn’t the > problem. > > Ralph
