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 d
> On Dec 22, 2021, at 9:20 AM, Volkan Yazıcı 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
Is the case that the log4j2 log4j-1.2-api is not on the classpath, but log4-1.2
itself is? Ideally we could detect that case and allow log4j1 to do its thing,
but that's easier said than done outside of standard cases (for instance when
interesting plugin/webapp classloaders are used)
On Wed, D
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,
rig
Volkan pointed out that the issue number in the subject was wrong.
Ralph
> On Dec 21, 2021, at 10:30 PM, Ralph Goers wrote:
>
> This ticket complains because ConfigurationFactory looks to see if a system
> property named log4j.configuration is set.
> If it is then it tries to initialize the co
