Forgotten: thanks a lot for the support.
Agree, additivity does not change much. The funny thing is that i get all
the logs anyway.
The file got messed in the paste: heve to add XX to param to paste it here
for some reason. It was:
<XXparam name="File" value="PROD.log"/>
<XXparam name="DatePattern" value="'.'yyyy-MM-dd"/>
<XXparam name="Append" value="false"/>
The file is created and filled up with all the mess i see on console. sasme
behaviour.
This is the main thing i dont understand: if it was the console only i would
presume messages comes from some other logging library, as you suggest. But
why should that library write into my file, and change name according with
my log4j settings?
I am not sure what iu should do with commons-logging.
at the moment there is commons-logging-api.jar in tomcat/bin and a
commons-logging-1.0.3.jar in tomcat/shared/lib. Does this have anything to
do? I think tomcat came like this, i dont remember changing it.
Should i put another copy of it in my web-inf/lib directory?
thanks again
Paolo
Based on this configuration, by setting additivity="false", you effectively
have no appenders attached to the loggers you've specified. Even if the
level
is "debug", you should get no output for the following loggers and their
children....
org.my
org.apache
org.hibernate
additivity="false" cuts off the inheritance tree. It can be useful, but not
the way you are using it. You should remove additivity="true" is the
default,
so you can exclude the additivity attribute altogether to get the
appropriate
behavior for you needs. Of course this brings us back to the original
problem
where you aren't seeing the logging behavior you expect to see. Read on....
You never answered my question on commons-logging or SLF4J. Many/Most
frameworks out there choose not to depend on a particular implementation,
choosing instread to depend on a more lightweight logger abstraction, such
as
the two mentioned. Both define how they interact with Log4j. For SLF4J,
you'd have to put the slf4j-api.jar and slf4j-log4j.jar in the classpath to
utilize log4j. For commons-logging, having commons-logging-api.jar means
you
will end up using JDK 1.4 logging. The API jar has no Log4j implementation.
What you would need is commons-logging.jar (without "-api" on the name).
BTW, for your "rolling" appender, it still doesn't appear that you define a
File for it unless you purposefully excluded it or it got messed up when
pasting it in to the email. Is the file getting created? At least the file
should be created even if there is no output. Does it get any output?
Maybe
remove the console appender from the config and only use a simple
FileAppender
instead of a rolling file appender. Once that works, you can add back
complexity.
BTW, what I usually do is set the <root> to <level value="warn"/>. Then I
define certain loggers to increase output as I need it. It's much easier to
do this than set the <root> at some lower level and then have to define
multiple loggers that I don't care about just to get them to shut up.
Anyway, keep trying. We'll track down the issue at some point here.
Jake
--
View this message in context:
http://www.nabble.com/Log-problem-with-Tomcat-5-%28lots-of-logs%29-tf4465225.html#a12758605
Sent from the Log4j - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
