Sorry, I was wrong. All the hivemind etc debug messages are still there. I am not sure what else i can check...
Paolo Scopa wrote: > > You are right, > common loggings came with tapestry. > I removed it from the shared/lib directory and copied version 1.1 in > web-inf/lib. > 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) > > WOAW > it looks it works!!! > Iam not sure why, but it does. > Thanks a lot. > Paolo > > (will let you know if it comes back ... :) ) > > > > Jacob Kjome wrote: >> >> On Tue, 18 Sep 2007 07:43:30 -0700 (PDT) >> Paolo Scopa <[EMAIL PROTECTED]> 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 >>>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] >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- View this message in context: http://www.nabble.com/Log-problem-with-Tomcat-5-%28lots-of-logs%29-tf4465225.html#a12779190 Sent from the Log4j - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
