[LOG4J2-3557] mule-3.3.1 with log4j-1.2-api-2.18.0 creates infinite recursion

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.18.0
• Fix Version/s: 2.19.0
• Component/s: Log4j 1.2 bridge
• Assignee: Piotr Karwasz
• Reporter: Andreas Leitgeb
• Created: 20/Jul/22 16:19
• Updated: 09/Sep/22 19:19
• Resolved: 07/Sep/22 18:22

Description

mule's class ApplicationAwareRepositorySelector has getLoggerRepository() method, and within that it eventually tries to create a RootLogger.

In old log4j-1.2.16.jar  this just created the RootLogger/Logger/Category hierarchy without any attempt to obtain a LoggerRepository. I disassembled the bytecode to check this.

in the  bridge, the c'tor of Category calls LogManager.getLoggerRepository() and that method ends up recursively calling mule's ApplicationAwareRepositorySelector.getLoggerRepository()

```
        at org.apache.log4j.LogManager.getLoggerRepository(LogManager.java:171)
        at org.apache.log4j.Category.<init>(Category.java:177)
        at org.apache.log4j.Category.<init>(Category.java:192)
        at org.apache.log4j.Logger.<init>(Logger.java:57)
        at org.apache.log4j.spi.RootLogger.<init>(RootLogger.java:39)
        at org.mule.module.launcher.log4j.ApplicationAwareRepositorySelector.getLoggerRepository(ApplicationAwareRepositorySelector.java:62)
```

At this point I cannot yet tell, if this is a horrible wrong-doing of mule, or just one of a number of horrible incompatibilities between the bridge and the old real log4j.

I'm aware that mule-3.3.1 is helplessly out of lifetime, but that's what I thought the bridge was meant for: to help upgrading SW that "cannot do log4j2."