Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: log4j error
Date: Sun, 18 Nov 2007 14:36:27 +0100
Message-ID: 
 <23AFECEB22D2FD47ADF828485803B2C003288622@MCHP7R5A.ww002.siemens.net>
In-Reply-To: 
 <2828B04F0113CD468E6D1D51DF4362A404005EBD@USEA-EXCH2.na.uis.unisys.com>
Thread-Topic: log4j error
Thread-Index: AcgorQLHUTrpdVYcRJOyje6KQQMZGQAAFlrQAE4gF5A=
References: <269225F0-15F7-4D41-90EB-ACAA77AA6F5C@mac.com>
 <2828B04F0113CD468E6D1D51DF4362A404005EBD@USEA-EXCH2.na.uis.unisys.com>
From: "Reich, Matthias" <matthias.reich@siemens.com>
To: "Tomcat Users List" <users@tomcat.apache.org>

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:Chuck.Caldarale@unisys.com]=20
Sent: Saturday, November 17, 2007 1:16 AM
To: Tomcat Users List
Subject: RE: log4j error

> From: Steven Crosley [mailto:stevencrosley@mac.com]=20
> Subject: log4j error
>=20
> log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
> log4j:ERROR [org.apache.catalina.loader.StandardClassLoader@cbf30e] =20
> whereas object of type
> log4j:ERROR "org.apache.log4j.ConsoleAppender" was loaded by =20
> [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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org