Hi, another approach is the use of a RepositorySelector. - you rely on the container to provide the log4j classes and to install a suitable RepositorySelector (should happen as early as possible, e.g. in a ServerLifeCycleListener) - each webapp can still provide it's own logging configuration - the RepositorySelector may provide some fallback mechanism, i.e. use a default Logger Repository in case the webapp does not provide it's own configuration.
I was once pointed to such a solution by the following article which explains the mechanism in more detail: http://www.qos.ch/logging/sc.jsp - Matthias -----Original Message----- From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] Sent: Saturday, November 17, 2007 1:16 AM To: Tomcat Users List Subject: RE: log4j error > From: Steven Crosley [mailto:[EMAIL PROTECTED] > Subject: log4j error > > log4j:ERROR The class "org.apache.log4j.Appender" was loaded by > log4j:ERROR [EMAIL PROTECTED] > whereas object of type > log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by > [WebappClassLoader This situation was reported earlier today in a different thread. The problem there was due to the following set of factors: 1) log4j*.jar in both Tomcat's lib directory and the webapp's WEB-INF/lib 2) classes from Tomcat's lib directory making references to log4j 3) classes from the webapp making references to log4j 4) classes from the webapp calling methods in classes from Tomcat's lib directory Even though the log4j jars may be identical, instances of log4j classes are not assignable across the different classloaders used for Tomcat's lib directory and the webapp. The quick fix is to get rid of the log4j*.jar in your WEB-INF/lib, but that precludes application-specifc logging. You could also move whatever classes from Tomcat's lib directory that the webapp needs into WEB-INF/lib, rather than having them in the common location. (This would be more in keeping with the servlet spec philosophy, which tries to keep webapps as independent as possible.) Or, you could rework your code a bit so the webapp passes a logging object to the methods that need it that come from Tomcat's lib directory, and insure that the shared classes don't hang onto that logger. There may be other solutions. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
