PS- I tried going direct to log4j, it still doesn't work right.
PS#2- Everything (all cases) work fine in a normal VM environment.
Kevin Ross
Kevin.Ross@bre
dex.com To: "Jakarta Commons Users List"
<[EMAIL PROTECTED]>
cc:
11/07/2002 Subject: Re: [Logging] Class loading
problems with Tomcat, struts & log4j
01:16 PM
Please respond
to "Jakarta
Commons Users
List"
Ahhh, the dreaded commons-logging + tomcat issue.
@see threads
http://www.mail-archive.com/cgi-bin/htsearch?method=and&format=short&config=tomcat-dev_jakarta_apache_org&restrict
&exclude=&words=kevin+ross
Remy said it would not be fixed. I haven't found a resolution, but I
*REALLY* need one. I just converted from a proprietary logging system,
that GREATLY depends on the ability to turn off logging for heirarchies.
This makes log4j a great fit. BUT, even after I have successfully worked
around the startup issue, the class name listed as the logging class name
is WRONG when within the tomcat 4.1.x environment.
Kevin Ross
Mike Wilcox
<Mike.Wilcox@a To:
[EMAIL PROTECTED]
epona.com> cc:
Subject: [Logging] Class
loading problems with Tomcat, struts & log4j
11/07/2002
06:08 AM
Please respond
to "Jakarta
Commons Users
List"
Hi,
I'm getting the following exceptions in my logs...
java.lang.ExceptionInInitializerError:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException:
org.apache.commons.logging.LogConfigurationException: Class
org.apache.commons.logging.impl.Log4JCategoryLog does not implement Log
which has appeared while upgrading Struts (from 1.1b1 to 1.1b nightly
from 5th Nov) and the commons-logging to 1.0.1. The exceptions come from
within the Struts XML parsing
Experience of this kind of thing (all too frequently) immediately points
me at a class loading issue caused by replicating the logging jar
file(s) in different places in the tomcat hierarchy. We had exactly
these kind of issues (but in Log4J) in getting the old setup to work,
and need to specially configure Log4J to not complain.
I know the likely cause, but what I haven't been able to work out is a
decent solution - either by trial & error, or by reference to tomcat,
log4j or commons mailing lists. I've tried any number of combinations of
the jar files, and I'm now stuck.
Is there anyone that can advise how to change our setup to make best use
of the commons-logging.jar, commons-logging-api.jar and log4j.jar files,
so I can get logging configured separately for different webapps? Any
good clues for how to set it up, or how *not* to set it up are welcomed!
Note that my problems aren't normally with getting configuration files
found/understood - we've gone through that pain, and know the tricks.
These problems are with the class loading..
Setup:
Tomcat is set as default, so class-loads within the webapp before
ascending the hierarchy.
Where we have the common-logging jar file, we choose the logging
implementation to be Log4J (by default, by making it available), and
configure it using a log4j.properties file.
We have a number of common jar files that are placed in [tomcat]/lib
(though they probably should be in [tomcat]/common/lib). Some of the
classes in these make use of commons-logging, so requires that the
commons-logging.jar file is also available up there (or higher in the
hierarchy). This in turn requires that we have the Log4J jar and
properties up there. Logging from these 'common' jar files should then
come out using this configuration.
Each web-app is then made of various components. Some parts have logging
based directly on Log4J, and some parts commons-logging. These
applications could make use of the 'common' jar files, but would then
also pick up the common configuration. Instead, we wish to be able to
configure the webapps differently (both from common, and from each
other). It appears that, for this to happen, we need to have both the
commons-logging and Log4J jar files, plus a log4j properties file within
the webapp directory.
Versions:
Tomcat 4.0.4
commons-logging 1.0.1
Struts 1.1beta (nightly 5th Nov)
Log4J 1.2.6
Cheers,
Mike
--
To unsubscribe, e-mail: <
mailto:commons-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <
mailto:commons-user-help@;jakarta.apache.org>
--
To unsubscribe, e-mail: <
mailto:commons-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <
mailto:commons-user-help@;jakarta.apache.org>
--
To unsubscribe, e-mail: <mailto:commons-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-user-help@;jakarta.apache.org>
