DO NOT REPLY [Bug 13157] New: - LogFactory property with Log4j

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13157>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13157

LogFactory property with Log4j

           Summary: LogFactory property with Log4j
           Product: Commons
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Logging
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: giacomo@apache.org


We've dicovered an issue with the current commons-logging code (1.0.2).

We have a servlet depoyed into a Servlet engine which has a log4j.jar in
its common classpath but our servlet (using commons-logging) need to used
logkit. We tried to use the system property
"org.apache.commons.logging.Log" set to
"org.apache.commons.logging.impl.LogKitLogger" as suggested with no luck.

So, we looked into the code and found that the constructor of
org.apache.commons.logging.impl.LogFactoryImpl is doing the following:

    public LogFactoryImpl() {
        super();
        guessConfig();
    }

and the guessConfig does:

    protected void guessConfig() {
        if( isLog4JAvailable() ) {
            proxyFactory = null;
            try {
                Class proxyClass=
                    loadClass(
"org.apache.commons.logging.impl.Log4jFactory" );
                if (proxyClass != null) {
                    proxyFactory = (LogFactory)proxyClass.newInstance();
                }
            } catch( Throwable t ) {
                ; // ignore
            }
        }
        // other logger specific initialization
        // ...
    }

Admittedly if have no idea what the proxyFactory is used for but for us
this means commons-logging does not respect the system property suggested
to use any other logging kit if there is a log4j in the classpath
anywhere.

Is this intentional?

By commenting the 'guessConfig()' call from the constructor we could solve
our problems but I'd really like to hear your oppinions about it.

Cheers

Giacomo

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>