You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Jean-frederic Clere <jf...@gmail.com> on 2006/02/26 23:27:01 UTC
Strange thing with jchevm/classpath
Hi,
I have a "strange" error:
+++
java.lang.NoSuchMethodError:
org/apache/log4j/Category.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljava/lang/Object;Ljava/lang/Throwable;)V
at java.lang.VMThrowable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Throwable.java:498)
at java.lang.Throwable.<init>(Throwable.java:159)
at java.lang.Error.<init>(Error.java:81)
at java.lang.LinkageError.<init>(LinkageError.java:72)
at
java.lang.IncompatibleClassChangeError.<init>(IncompatibleClassChangeError.java:71)
at java.lang.NoSuchMethodError.<init>(NoSuchMethodError.java:72)
at java.lang.VMClass.forName(Native Method)
at java.lang.Class.forName(Class.java:161)
at toto.main(toto.java:8)
+++
Looking log4j I have found the following in Category.java:
+++
void log(String callerFQCN, Priority level, Object message, Throwable t)
+++
and in Level.java :
+++
public class Level extends Priority implements Serializable {
+++
So why is the method log no found?
The code used to reproduce the problem is the following:
+++
import java.lang.reflect.Constructor;
public class toto {
public static void main(String argv[]) {
Class myclass[] = { java.lang.String.class };
try {
Class logClass =
Class.forName("org.apache.commons.logging.impl.Log4JLogger");
Constructor titi =
logClass.getConstructor(myclass);
} catch(Exception e) {
e.printStackTrace();
}
}
}
+++
Any hints?
Cheers
Jean-Frederic
Re: Strange thing with jchevm/classpath
Posted by Jean-frederic Clere <jf...@gmail.com>.
Archie Cobbs wrote:
> Jean-frederic Clere wrote:
>
>>> So either something weird is happening (always possible), or you
>>> have some
>>> other incompatible version of log4j on your classpath, or something
>>> in your classpath was compiled against another version of log4j, etc.
>>
>>
>> My test is using:
>> Class.forName("org.apache.commons.logging.impl.Log4JLogger");
>> I have rebuild commons-logging using the log4j I am using in the test
>> and the test is working now.
>> But I still don't understand why it was working with the Sun JVM
>> before!!!
>
>
> Probably due to classpath differences. E.g. do you have a CLASSPATH
> environment variable set? Sun pays attention to it, jchevm does not.
That seems not to be a CLASSPATH problem, with the Sun JVM the used jar
files are:
+++
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/rt.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/sunrsasign.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/jsse.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/jce.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/charsets.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/ext/dnsns.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/ext/sunjce_provider.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/ext/ldapsec.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/JAVA/j2sdk1.4.2_06/jre/lib/ext/localedata.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/TOMCAT/apache-tomcat-5.5.15/common/lib/commons-logging.jar",
O_RDONLY|O_LARGEFILE) = 3
open("/home/jfclere/TOMCAT/apache-tomcat-5.5.15/common/lib/log4j-1.2.13.jar",
O_RDONLY|O_LARGEFILE) = 3
+++
jc uses the same common-logging and log4j jar files...
Geir idea is also a good hint:
The lastest commons-logging is from 15-Jun-2004, it was not compiled
with log4j-1.2.13 but with something else.
I have tried this commons-logging with logging-log4j-1.3alpha-8 and jc
works ok.
I think I will ask commons-dev@jakarta.apache.org about it ;-)
Cheers
Jean-Frederic
>
> -Archie
>
> __________________________________________________________________________
>
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
>
Re: Strange thing with jchevm/classpath
Posted by Archie Cobbs <ar...@dellroad.org>.
Jean-frederic Clere wrote:
>> So either something weird is happening (always possible), or you have
>> some
>> other incompatible version of log4j on your classpath, or something
>> in your classpath was compiled against another version of log4j, etc.
>
> My test is using:
> Class.forName("org.apache.commons.logging.impl.Log4JLogger");
> I have rebuild commons-logging using the log4j I am using in the test
> and the test is working now.
> But I still don't understand why it was working with the Sun JVM before!!!
Probably due to classpath differences. E.g. do you have a CLASSPATH
environment variable set? Sun pays attention to it, jchevm does not.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Strange thing with jchevm/classpath
Posted by Jean-frederic Clere <jf...@gmail.com>.
Archie Cobbs wrote:
> Jean-frederic Clere wrote:
>
>>>> I am using logging-log4j-1.2.13 and I have downloaded it.
>>>
>
> There is no such method:
>
> org/apache/log4j/Category.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljava/lang/Object;Ljava/lang/Throwable;)V
>
>
> in the JAR file that comes with that version of log4j.
>
> So either something weird is happening (always possible), or you have
> some
> other incompatible version of log4j on your classpath, or something
> in your classpath was compiled against another version of log4j, etc.
My test is using:
Class.forName("org.apache.commons.logging.impl.Log4JLogger");
I have rebuild commons-logging using the log4j I am using in the test
and the test is working now.
But I still don't understand why it was working with the Sun JVM before!!!
Cheers
Jean-Frederic
>
> -Archie
>
> __________________________________________________________________________
>
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
>
Re: Strange thing with jchevm/classpath
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Archie Cobbs wrote:
> Jean-frederic Clere wrote:
>>>> I am using logging-log4j-1.2.13 and I have downloaded it.
>
> There is no such method:
>
> org/apache/log4j/Category.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljava/lang/Object;Ljava/lang/Throwable;)V
>
>
> in the JAR file that comes with that version of log4j.
>
> So either something weird is happening (always possible), or you have some
> other incompatible version of log4j on your classpath, or something
> in your classpath was compiled against another version of log4j, etc.
That could be. I think that there was a major incompatible change made
to log4j between 1.2 and 1.3
geir
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
>
Re: Strange thing with jchevm/classpath
Posted by Archie Cobbs <ar...@dellroad.org>.
Jean-frederic Clere wrote:
>>> I am using logging-log4j-1.2.13 and I have downloaded it.
There is no such method:
org/apache/log4j/Category.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljava/lang/Object;Ljava/lang/Throwable;)V
in the JAR file that comes with that version of log4j.
So either something weird is happening (always possible), or you have some
other incompatible version of log4j on your classpath, or something
in your classpath was compiled against another version of log4j, etc.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Strange thing with jchevm/classpath
Posted by Jean-frederic Clere <jf...@gmail.com>.
Archie Cobbs wrote:
> Jean-frederic Clere wrote:
>
>>> However, how did the classes change? I tried to reproduce this
>>> with log4j-1.2.13 but couldn't.
>>
>>
>> I am using logging-log4j-1.2.13 and I have downloaded it.
>>
>>> Can you give more detail on how
>>> you compiled Classpath and what version of log4j you're using?
>>
>>
>> That is on a debian machine I have used apt-get install to install it.
>
>
> I can't tell what the problem is without more info. You could try
> running with --verbose=class to see where jchevm is looking for
> class files.
Find enclosed the input of jc --verbose=class
>
> -Archie
>
> __________________________________________________________________________
>
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
>
Re: Strange thing with jchevm/classpath
Posted by Archie Cobbs <ar...@dellroad.org>.
Jean-frederic Clere wrote:
>> However, how did the classes change? I tried to reproduce this
>> with log4j-1.2.13 but couldn't.
>
> I am using logging-log4j-1.2.13 and I have downloaded it.
>
>> Can you give more detail on how
>> you compiled Classpath and what version of log4j you're using?
>
> That is on a debian machine I have used apt-get install to install it.
I can't tell what the problem is without more info. You could try
running with --verbose=class to see where jchevm is looking for
class files.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Strange thing with jchevm/classpath
Posted by Jean-frederic Clere <jf...@gmail.com>.
Archie Cobbs wrote:
> Jean-frederic Clere wrote:
>
>> I have a "strange" error:
>> +++
>> java.lang.NoSuchMethodError:
>> org/apache/log4j/Category.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljava/lang/Object;Ljava/lang/Throwable;)V
>>
>> at java.lang.VMThrowable.fillInStackTrace(Native Method)
>> at java.lang.Throwable.fillInStackTrace(Throwable.java:498)
>> at java.lang.Throwable.<init>(Throwable.java:159)
>> at java.lang.Error.<init>(Error.java:81)
>> at java.lang.LinkageError.<init>(LinkageError.java:72)
>> at
>> java.lang.IncompatibleClassChangeError.<init>(IncompatibleClassChangeError.java:71)
>>
>> at java.lang.NoSuchMethodError.<init>(NoSuchMethodError.java:72)
>> at java.lang.VMClass.forName(Native Method)
>> at java.lang.Class.forName(Class.java:161)
>> at toto.main(toto.java:8)
>> +++
>>
>> Looking log4j I have found the following in Category.java:
>> +++
>> void log(String callerFQCN, Priority level, Object message, Throwable t)
>> +++
>> and in Level.java :
>> +++
>> public class Level extends Priority implements Serializable {
>> +++
>> So why is the method log no found?
>
>
> The method matching algorithm that would allow a method having
> 2nd parameter type "Priority" to be used for an invocation that
> has a 2nd parameter of type "Level" happens during compilation,
> not runtime. In other words, an "incompatible class change" has
> truly occurred it seems and in such a case the exception is
> expected.
>
> However, how did the classes change? I tried to reproduce this
> with log4j-1.2.13 but couldn't.
I am using logging-log4j-1.2.13 and I have downloaded it.
> Can you give more detail on how
> you compiled Classpath and what version of log4j you're using?
That is on a debian machine I have used apt-get install to install it.
>
> -Archie
>
> __________________________________________________________________________
>
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
>
Re: Strange thing with jchevm/classpath
Posted by Archie Cobbs <ar...@dellroad.org>.
Jean-frederic Clere wrote:
> I have a "strange" error:
> +++
> java.lang.NoSuchMethodError:
> org/apache/log4j/Category.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljava/lang/Object;Ljava/lang/Throwable;)V
>
> at java.lang.VMThrowable.fillInStackTrace(Native Method)
> at java.lang.Throwable.fillInStackTrace(Throwable.java:498)
> at java.lang.Throwable.<init>(Throwable.java:159)
> at java.lang.Error.<init>(Error.java:81)
> at java.lang.LinkageError.<init>(LinkageError.java:72)
> at
> java.lang.IncompatibleClassChangeError.<init>(IncompatibleClassChangeError.java:71)
>
> at java.lang.NoSuchMethodError.<init>(NoSuchMethodError.java:72)
> at java.lang.VMClass.forName(Native Method)
> at java.lang.Class.forName(Class.java:161)
> at toto.main(toto.java:8)
> +++
>
> Looking log4j I have found the following in Category.java:
> +++
> void log(String callerFQCN, Priority level, Object message, Throwable t)
> +++
> and in Level.java :
> +++
> public class Level extends Priority implements Serializable {
> +++
> So why is the method log no found?
The method matching algorithm that would allow a method having
2nd parameter type "Priority" to be used for an invocation that
has a 2nd parameter of type "Level" happens during compilation,
not runtime. In other words, an "incompatible class change" has
truly occurred it seems and in such a case the exception is
expected.
However, how did the classes change? I tried to reproduce this
with log4j-1.2.13 but couldn't. Can you give more detail on how
you compiled Classpath and what version of log4j you're using?
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com