[jira] Updated: (LOGGING-44) LogFactory property with Log4j

["Dennis Lundberg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LOGGING-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Lundberg updated LOGGING-44:
-----------------------------------

    Affects Version/s: 1.0.2
        Fix Version/s: 1.0.3

> LogFactory property with Log4j
> ------------------------------
>
>                 Key: LOGGING-44
>                 URL: https://issues.apache.org/jira/browse/LOGGING-44
>             Project: Commons Logging
>          Issue Type: Bug
>    Affects Versions: 1.0.2
>         Environment: Operating System: All
> Platform: All
>            Reporter: Giacomo Pati
>             Fix For: 1.0.3
>
>
> 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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.