[jbossts-issues] [JBoss JIRA] Commented: (JBTM-325) Reconcile conflicting overrides of commons-logging Log4JLogger

[Jonathan Halliday (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBTM-325?page=comments#action_12401874 ] 
            
Jonathan Halliday commented on JBTM-325:
----------------------------------------

Updated JBossTS trunk r18777 to use the (stock apache, not JBoss patched) 1.1.0 version of commons-logging. It previously used 1.0.3.  This involved changing .jar file name in build scripts and runtime classpath shell scripts plus 3rd party licence file.  Updated 2 classes in our code base that are actually modified versions of apache logging classes. One of those is the one that did not have trace level.  Now it's based on 1.1.0 it does have. However that may be irrelevant because I also changed our factory classes so they remove the override of the apache factory attribute after use, which should mean JBossAS sees its own log version, not the one from JBossTS. Note that factory config is basically global so due to absence of thread safety the AS may occasionally still get the wrong log impl.  Ultimately this problem won't go away until we have an I18N logging solution used by all JBoss projects or commons-logging has a thread safe approach to allowing multiple different factory configs to coexist.

> Reconcile conflicting overrides of commons-logging Log4JLogger
> --------------------------------------------------------------
>
>                 Key: JBTM-325
>                 URL: http://jira.jboss.com/jira/browse/JBTM-325
>             Project: JBoss Transaction Manager
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Common
>    Affects Versions: 4.3.0.BETA2
>            Reporter: Brian Stansberry
>         Assigned To: Jonathan Halliday
>
> As part of the fix for JBTM-20, JBossTS instructs Jakarta Commons Logging to use com.arjuna.common.internal.util.logging.jakarta.Log4JLogger as its implementation of the JCL Log interface.  This supersedes an alternate override of the default JCL behavior that JBoss AS had in place.  The AS is using a special forked version of JCL 1.1.0 known as 1.1.0.jboss.  The fork involves changing the org.apache.commons.logging.Log4JLogger class to better support use of separate log4j subsystems between different deployments.
> We need to reconcile these two conflicting overrides of the default JCL behavior and make sure the goals of each are fulfilled. At the moment, I'm aware of two things the AS fork was doing that the com.arjuna version is not:
> 1) Support for trace level logging -- the com.arjuna class seems to be based on older code and maps trace to debug.
> 2) Support for not binding of org.apache.log4j classes, using the TCCL to  load the log4j classes when a Log4JLogger instance is created and using reflection to invoke upon them.
> The AS fork isn't doing any of the i18n stuff that AIUI the JBossTS version does.
> The source for the AS fork of JCL can be found at:
> 1) https://svn.jboss.org/repos/repository.jboss.org/apache-logging/1.1.0.jboss/lib/commons-logging-src.zip 
> 2) cvs -d:ext:starksm at cvs.forge.jboss.com:/cvsroot/jboss co apache  
> CVS tag for the 1.1.0.jboss release is JBoss_Apache_Common_Logging_1_1_0

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira