Quoting Mike Curwen [EMAIL PROTECTED]:
Hi all,
I've been using log4j for some time and like it quite a bit. My configs are
probably naieve, but they work for me. But now, another developer has
pointed something out to me, and yup.. something's busted. I'm posting this
to tomcat-user because I'm thinking it might be a TC/mywebapp conflict of
some kind (though I'm not sure where).
Tomcat 5.0.29
log4j 1.2.1 in my webapp's WEB-INF/lib
You should upgrade. You very well may be running into bugs in early versions of
1.2.x. Upgrade to 1.2.9, the current release and test again.
log4j.properties in my webapp's WEB-INF/classes directory.
I don't have log4j.jar anywhere else and no other log4j.properties files
anywhere, though perhaps I don't know where to look.
One way to check is to remove log4j.properties from WEB-INF/classes and see if
autoconfiguration happens. You would know this by seeing messages from Log4j
saying something like there are no appenders configured for this logger. If
you don't see messages like that, then Log4j is finding a config file somewhere
else. Log4j looks in the default package (no package) for config files. If a
config file were in a jar file, it would be in the root of the jar file.
In our JSP pages we have loggers declared like so:
%@ page import=org.apache.log4j.Logger %
%!
Logger logger = Logger.getLogger(pages.abc.page_name);
%
%
logger.debug(foo);
%
pages is common throughout every JSP. abc would be a folder name (we've
got the webapp organized into folders of related functions), and finally
page_name is the name of the JSP file without extension.
our log4j.properties file is:
#log4j.properties
log4j.rootCategory=DEBUG, filer
log4j.category.com.gb.security=WARN, filer
log4j.additivity.com.gb.security=false
log4j.appender.filer=org.apache.log4j.RollingFileAppender
log4j.appender.filer.layout=org.apache.log4j.PatternLayout
log4j.appender.filer.layout.ConversionPattern=%-5p %c - [%m] %d{ISO8601}%n
log4j.appender.filer.File=/path/to/the/log/file/debug.log
log4j.appender.filer.MaxFileSize=100KB
log4j.appender.filer.MaxBackupIndex=4
As you'll see we've got the root category to DEBUG and we've piped down our
com.gb.security package to WARN. We've got lots of other classes, both
bundled in WEB-INF/lib jar files and loosely in the WEB-INF/classes and
they all spill their log4j output.
But none of our log messages from the JSP pages are coming through. I've
tried the following config, but it had no effect:
log4j.category.pages=DEBUG, filer
log4j.additivity.pages=false
*If* I configure the following (adding a 'package' below 'pages'):
log4j.category.pages.abc=DEBUG, filer
log4j.additivity.pages.abc=false
Then it will work (but obviously only for pages under 'abc'). Also, if I
remove the additivity, I get two messages. That makes me think there's one
message from the rootCategory, and one from this category. But when I
remove the category 'pages.abc' entirely, we're back to nothing again.
Any ideas? Is there a TC log4j or CL file hiding somewhere?
If changes to your config file are being recognized, then it probably isn't a
problem with Log4j using some other config file. I don't know why your
original config wouldn't work. It really should.
One note. You shouldn't be using rootCategory and category, but
rootLogger, and logger. Also, additivity is only necessary when you are
trying to log to a different appender than those of the current logger is
inheriting. Since you've specified the filer appender to the root, you can
simply define the level you want to reset your named logger to rather than also
supplying the filer appender and setting additivity to false.
Oh, one other thing. I don't know for sure whether order is important in
properties files, but you might define your appenders first and loggers last
with the rootLogger last. In Log4j XML config files, order is important and
enforced by the dtd (which is not necessary to use with Logj4-1.3, not yet
released, at least non-alpha).
Jake
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
