[jira] [Commented] (LOG4J2-3557) mule-3.3.1 with log4j-1.2-api-2.18.0 creates infinite recursion

["Piotr Karwasz (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572246#comment-17572246 ] 

Piotr Karwasz commented on LOG4J2-3557:
---------------------------------------

Hi [~avl42],

I agree with you that {{Category}} should not use the static method {{LogManager.getLoggerRepository()}} to find the logger repository that instantiated it. I corrected the error in the newest {{2.18.1-SNAPSHOT}} you can find at [https://repository.apache.org/snapshots].

However this will *not* fix the logic behind the [ApplicationAwareRepositorySelector|https://github.com/mulesoft/mule/blob/37cd988e92a0364ecf49aea09720db6023319d17/modules/launcher/src/main/java/org/mule/module/launcher/log4j/ApplicationAwareRepositorySelector.java]: in the {{log4j-1.2-api}} bridge the {{Hierarchy}} object is stateless and it delegates to the Log4j2 {{ContextSelector}} the task of choosing the correct context. Therefore the task of configuring a different configuration per Mule application will fail.

You should rather disable the {{ApplicationAwareRepositorySelector}} (setting the "mule.simpleLog" system property according to the [source code|https://github.com/mulesoft/mule/blob/37cd988e92a0364ecf49aea09720db6023319d17/modules/launcher/src/main/java/org/mule/module/launcher/MuleContainer.java#L81]) and use one of the configurations described in [Log4j Logging Separation|https://logging.apache.org/log4j/2.x/manual/logsep.html].

> mule-3.3.1 with log4j-1.2-api-2.18.0 creates infinite recursion
> ---------------------------------------------------------------
>
>                 Key: LOG4J2-3557
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-3557
>             Project: Log4j 2
>          Issue Type: Question
>          Components: Log4j 1.2 bridge
>    Affects Versions: 2.18.0
>            Reporter: Andreas Leitgeb
>            Priority: Major
>
> 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."



--
This message was sent by Atlassian Jira
(v8.20.10#820010)