Pat, Good detective work. I find it hard to believe that JDK 1.4 should have a bug in its reflection code although the fact that switching to JDK 1.3 solved the problem comforts the theory of a bug in JDK 1.4.
The last time I was confronted with a JDK bug was in 998 or so in IBM's JDK 1.1.6 implementation on AIX. These things do not happen very often... At 15:59 05.06.2002 -0400, [EMAIL PROTECTED] wrote: >Ceki, > > > Remove log4j.jar from the CLASSPATH and from $JAVA_HOME/jre/lib/ext/ > > if that is the case. > > > > If log4j.jar is not on the CLASSPATH or $JAVA_HOME/jre/lib/ext/ check > > also $CATALINA_HOME/common/lib and $CATALINA_HOME/lib. > >I checked my CLASSPATH and directories $JAVA_HOME/jre/lib/ext, >$CATALINA_HOME/common/lib, and $CATALINA_HOME/lib, and none of them had >a log4j*.jar file in them. > >I then edited class PropertySetter and added some more debugging code that >would tell me the type of the object for which a property was being >set. The output of this debugging code indicated that there was no problem >using the same object variable to set properties for different types of >objects within the same web application. However, as soon as the class >was called to set a property for an object in another web application, >it generated the same error again. > >In my search for a solution to this problem, I found the following two >postings: > >1) http://www.kaffe.org/pipermail/kaffe/2001-July/007381.html > > Date of posting: July 24, 2001. > > This posting uses an example to demonstrate the type of behavior I was > getting with my web applications, and gives a brief explanation of the > cause for the behavior. The following is a snippet of this posting: > > when the Method-Object is constructed (via getMethod(...)), it saves > the class it's constructed from and it's "method slot"-number. So in > the second case, we have a Method that believes to be "Method #0 in > class A", while the first Method object is "Method #6 in B". > Unfortunately, when Method.invoke() is called, the following happens > (in a nutshell): the runtime class of the object-argument of > Method.invoke() and the slot number (index) in the Method are combined > to find the code to be executed: so in the first case, we call method > #6 in class B, which *really is* foo(). But in the second case we > execute method #0 (!!!!) in class B, which happens to be > object.clone(), leading to the shown exception. > >2) >http://www.apachelabs.org/tomcat-user/200201.mbox/%3c009901c1950f$eebf7f60$[EMAIL PROTECTED]%3e > > Date of posting: January 4, 2002. > > This is a posting by Remy Maucherat, who is also a Jakarta developer (he > works on the Tomcat and Slide Subprojects). > > Remy basically confirmed that there is a bug in JDK 1.4 (I was using > j2sdk1.4.0) that causes this problem and suggested that people use >another > JDK version. > > So, I reverted back to j2sdk1_3_1_01, and started tomcat again, and this > time the log4j initialization worked fine for both of my web >applications. > >Ceki, thank you very much for your help and also for writing log4j. >I really like it so far! > >Pat > > >Patricia T. Guimaraes >Software Engineer >Gene Logic, Inc. -- Ceki SUICIDE BOMBING - A CRIME AGAINST HUMANITY Sign the petition: http://www.petitiononline.com/1234567b I am signatory number 22106. What is your number? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
