> 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
