Whitney, To convince yourself that the error is linked to having two distinct copies of log4j classes present in memory each of which is accessible by a different class loader, as well as the TCL settings as desribed in an earlier mail, you can use log4j 1.2.1 which does not use the TCL. Log4j 1.2.1 is available here:
http://jakarta.apache.org/log4j/jakarta-log4j-1.2.1.tar.gz (Log4j 1.2.1 ignores the TCL.) Please let us know if using log4j 1.2.1 solves the problem. At 00:07 14.07.2002 +0200, Ceki Gülcü wrote: >The error ["org.apache.log4j.DailyRollingFileAppender" object is not >assignable to a "org.apache.log4j.Appender" variable.] means in no >uncertain terms that two distinct copies of log4j classes are present >in memory each of which is accessible by a different class >loader. > >Here is a typical scenario. Let us assume that log4j.jar is accessible >on the system class loader (the classloader in charge of the >CLASSPATH) as well as to the classloader that is associated with >WEB-INF/lib. Let S be the system classloader and W the WEB-INF/lib >classloader. Let us also assume that the Thread Context Classloader is >not set. Code loaded by W trying to configure log4j by invoking >PropertyConfigurator will generate the [object is not assignable] >error because PropertyConfigurator (loaded by W) will attempt to load >appender classes using the Thread Context Classloader which defaults >to S, if not set. However, copies of the same class loaded by >different class loaders are incompatible. Hence the object is not >assignable message... > >This is consistent with the behavior you observe because the TCL can >evolve during the life cycle of a web-application. > >Did I mention that the problem is due to having two distinct copies of >log4j classes being present in memory each of which is accessible by a >different class loader? > >At 19:24 12.07.2002 -0400, you wrote: >>Ceki, >> Thanks for your response; I've done some more digging and discovered >> the following behavior. >> >> >> As I said before when I first start jrun, everything is perfectly fine; >> if I touch then my servlet class, causing Jrun to dynamically destroy it >> and reload it, this causes log4j to report the following: >> >> >>log4j:ERROR A "org.apache.log4j.DailyRollingFileAppender" object is not >>assignable to a "org.apache.log4j.Appender" variable. >>log4j:ERROR Could not instantiate appender named "A1". >>log4j:ERROR A "org.apache.log4j.net.SMTPAppender" object is not >>assignable to a "org.apache.log4j.Appender" variable. >>log4j:ERROR Could not instantiate appender named "ML". >>log4j:WARN No appenders could be found for logger (HelloSso2Servlet). >>log4j:WARN Please initialize the log4j system properly. >> >>I indicated this before. Now, perhaps you can explain the following: >> >>If I then programmatically cause the servlet to call its own init() >>method later, after it has already been instantiated (when log4j failed >>to initialize), then everything returns to normal and log4j correctly >>initializes. >> >>Why does that happen? It's as if log4j cannot initialize when jrun first >>dynamically reloads the servlet-- but later, after the servlet has been >>instantiated, the PropertyConfigurator is successful. >> >>Is there some sort of race condition? How can I get around this? >> >>Thanks again, >>Whit > >-- >Ceki > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
