I've got an application running in mule-3.3.1 which itself uses log4j-version 1. My task is to upgrade all usages of old log4j in our applications.
I replaced the log4j-1*.jar by log4j2 jar files (api, core and the bridge) and set the properties needed to use old "log4j.properties".
Now, on startup it crashes with a java.lang.StackOverflowError, and the repeating block of the stacktrace is as follows:
at org.mule.module.launcher.log4j.ApplicationAwareRepositorySelector.getLoggerRepository(ApplicationAwareRepositorySelector.java:62)
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)
The story is: mule's ApplicationAwareRepositorySelector.getLoggerRepository() wants to log something, and ends up being called from the log4j-bridge, which uses "invokeinterface" on
org/apache/log4j/spi/RepositorySelector.getLoggerRepository:()Lorg/apache/log4j/spi/LoggerRepository;
and the implementing class is exactly org.mule.module.launcher.log4j.ApplicationAwareRepositorySelector
Mule 3.3.x is not designed to use newer versions of log4j. Newer versions of Mule that received upgraded versions of log4j to fix security vulnerabilities also required additional patches to be able to upgrade the log4j version.
Additionally Mule 3.3 is so old, and in end of life for so many years that it probably contains many other security vulnerabilities in the libraries it uses that upgrading only log4j should be the lesser of your problems.
My recommendation is to just upgrade to an already supported and patched Mule 3.x version like Mule 3.9.5 with the latest security patches.
It would be better to migrate to Mule 4 if you can but the effort may be significantly higher.