loggerFactory configuration ignored

[augustd <au...@codemagi.com>]

I have subclassed Logger (org.owasp.esapi.Log4JLogger) and created a
LoggerFactory implementation to return instances of my logger. I configure
it in log4j.xml like this:

<loggerFactory class="org.owasp.esapi.reference.Log4JLoggerFactory"/>

However, in order to have log4j create Loggers that are instances of the
subclass, you must specify a <logger> in log4j.xml for every class which
will use the subclassed Logger. For example, if I specify a logger:

<logger name="com.mycompany.mypackage.MyClass">
    <level value="info"/>
</logger>

This will give me an instance of Log4JLogger, as this logger will be created
during the parsing of the configuration file. However, if I attempt to
specify a package-level logger:

<logger name="com.mycompany.mypackage">
    <level value="info"/>
</logger>

And then I instantiate an ad-hoc Logger in code (say
in om.mycompany.mypackage.MyOtherClass):

Logger log = Logger.getLogger(this.getClass());

I will get an instance of org.apache.log4j.Logger instead
of org.owasp.esapi.Log4JLogger. Looking at the code, it seems like the
LoggerFactory is only used during the initial parsing of the configuration
file in DOMConfigurator. Subsequent ad-hoc Loggers are created by
Hierarchy.getLogger(), which only uses a default LoggerFactory:

  public Logger getLogger(String name) {
    return getLogger(name, defaultFactory);
  }

It seems like it should be easy enough for DOMConfigurator to set the
defaultFactory in Hierarchy at startup so that subsequent loggers are
constructed with the specified factory.

If I make this bug fix, what are the chances of getting it rolled into the
Log4J core? What is the release schedule like? Are there any plans in the
works to release a new version on the 1.2.x branch?

The purpose of this logger subclass is to add auditing features and
protections for log injection attacks in security critical environments.
Given the sheer number of classes and libraries that use Log4J, a code
change to call Logger.getLogger(Class, LogFactory) is not practical, so it
is imperative that we be able to override the LoggerFactory application-wide
at the configuration level.

Thanks,
August