logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Scopa <paolosc...@yahoo.com>
Subject Re: Log problem with Tomcat 5 (lots of logs)
Date Wed, 19 Sep 2007 13:53:59 GMT

You are right,
common loggings came with tapestry.
I removed it from the shared/lib directory and copied version 1.1 in
Copied in the tomcat bin folder the common-loggings-api.jar.

Also i set the root logger level to warning and or.my logger to debug (i did
it before with no effects)

it looks it works!!!
Iam not sure why, but it does.
Thanks a lot.

(will let you know if it comes back ... :) )

Jacob Kjome wrote:
> On Tue, 18 Sep 2007 07:43:30 -0700 (PDT)
>   Paolo Scopa <paoloscopa@yahoo.com> wrote:
>>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.
> Well, you must have because Tomcat doesn't ship with anything in
> shared/lib. 
>  BTW, I would replace that with commons-logging-1.1.jar.  Many
> classloading 
> bugs have been fixed in the latest version of commons-logging.
>> Should i put another copy of it in my web-inf/lib directory?
> Absolutely, yes.  Anywhere log4j.jar goes, put a copy of 
> commons-logging-1.1.jar.  Same goes for SLF4J, if it is required by any 
> libraries.  Let us know if that changes anything.
> Jake
>> 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
>> 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: 
>> Sent from the Log4j - Users mailing list archive at Nabble.com.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>For additional commands, e-mail: log4j-user-help@logging.apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org

View this message in context: http://www.nabble.com/Log-problem-with-Tomcat-5-%28lots-of-logs%29-tf4465225.html#a12777963
Sent from the Log4j - Users mailing list archive at Nabble.com.

To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message