Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions

[robert burrell donkin]

hi ceki
i've committed a patch along the lines you've proposed. many thanks :)
i've added some optional unit tests that give me confidence that a  
version of commons-logging compiled against log4j CVS HEAD will run  
against 1.2.7. it'd be a good idea to find a way for gump to run this  
test (but i'm not too sure at the moment how to do this). i'll probably  
add another where the log4j 1.3 jar is explicitly specified tomorrow.

running a version compiled against 1.2.x to run against 1.3 would be  
nice but not critical. i suspect that your code will only work one way  
but i'd be glad to be proved wrong. maybe i'll find time to take a look  
into this tomorrow.

- robert
On 19 May 2004, at 14:53, Ceki Gülcü wrote:
With some changes to log4j HEAD and the following patch to
commons-logging, it is now possible to compile commons-logging with
1.3alpha and run it with both 1.3 *and* 1.2.8. Unfortunately, I was
unable to get a c-l version compiled with 1.2.8 to also run with 1.3.  
Mostly because I am unable to grok the java.lang.VerifyError.

     [java] No suitable Log constructor [Ljava.lang.Class;@f9f9d8 for  
org.apache.commons.logging.impl.Log4JLogger
     [java] java.lang.VerifyError: (class:  
org/apache/commons/logging/impl/Log4JLogger, method: warn signature:  
(Ljava/lang/Object;Ljava/lang/Throwable;)V) Incom
patible argument to function
     [java]     at java.lang.Class.getDeclaredConstructors0(Native  
Method)
     [java]     at  
java.lang.Class.privateGetDeclaredConstructors(Class.java:1590)
     [java]     at java.lang.Class.getConstructor0(Class.java:1762)
     [java]     at java.lang.Class.getConstructor(Class.java:1002)
     [java]     at  
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFac 
toryImpl.java:410)
     [java]     at  
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryIm 
pl.java:531)
     [java]     at  
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryIm 
pl.java:235)
     [java]     at  
org.apache.commons.logging.LogFactory.getLog(LogFactory.java:369)
     [java]     at  
org.apache.commons.logging.log4j.DefaultConfigTestCase.setUpLog(Default 
ConfigTestCase.java:179)
     [java]     at  
org.apache.commons.logging.log4j.DefaultConfigTestCase.setUp(DefaultCon 
figTestCase.java:81)
     [java]     at junit.framework.TestCase.runBare(TestCase.java:125)
     [java]     at  
junit.framework.TestResult$1.protect(TestResult.java:106)
     [java]     at  
junit.framework.TestResult.runProtected(TestResult.java:124)
     [java]     at junit.framework.TestResult.run(TestResult.java:109)
     [java]     at junit.framework.TestCase.run(TestCase.java:118)
     [java]     at  
junit.framework.TestSuite.runTest(TestSuite.java:208)
     [java]     at junit.framework.TestSuite.run(TestSuite.java:203)
     [java]     at junit.textui.TestRunner.doRun(TestRunner.java:116)
     [java]     at junit.textui.TestRunner.start(TestRunner.java:172)
     [java]     at junit.textui.TestRunner.main(TestRunner.java:138)

I would be interested if someone could explain the source of the error.
Anyway, to get 1.3 compiled code to also run on 1.2.8, the trick is to
detect if running on 1.2 and to cast a Level instance as a Priority.
The detection is straightforward:
 private static final boolean is12 =  
Priority.class.isAssignableFrom(Level.class);

In Log4jLogger class, the various method calls become:
 public void debug(Object message) {
   if(is12) {
     getLogger().log(FQCN, (Priority) Level.DEBUG, message, null );
   } else {
     getLogger().log(FQCN, Level.DEBUG, message, null );
   }
 }
Refer to the included patch file for exact details.
Note also that the CustomConfigTestCase.java was modified to reflect
the fact that the throwable is no longer available in ThrowableInfo.
At 02:57 PM 5/19/2004, Mario Ivankovits wrote:
Shapira, Yoav wrote:
It'd be easy to do conditional stuff, as Joran for example is  
completely
new in log4j 1.3, with Ant's <available> tasks and related  
conditionals.

I am not sure, if the "conditional stuff" helps. If you end up not  
being binary-compatible, i think commons-logging needs two  
compile-steps.
One with log4j-1.2.8 in the classpath, and one with log4j-1.3 for the  
Log4J13Logger and then package them together in one jar.

If we would like to avoid this, we could also use reflection at all  
to call those log( methods, but this might result in an performance  
loss.

-- Mario
--
Ceki Gülcü
     For log4j documentation consider "The complete log4j manual"
     ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]