[
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.jbo...
2) cvs -d:ext:starksm@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