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. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
