Let's turn this into a question. How do we want to be able to configure Tapestry logging?
I have found the rather verbose logging to be beneficial in figuring out what listeners are being fired when using naming conventions rather than explicit OnEvent configuration. However, it has also obscured my own logging statements so I understand your frustration. Is it sufficient to have the Tapestry class-enhancement and event dispatch logging controlled by the Tapestry SymbolConstants.PRODUCTION_MODE flag? Should it be a separate app-wide flag? Should it be configurable on a class-by-class basis? I know I would prefer to be able to toggle it on the fly without a restart. Jonathan > -----Original Message----- > From: Fernando Padilla [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 22, 2008 13:56 > To: Tapestry users > Subject: Re: so much useless logging > > Most people use Log4j, so I don't think suggesting "Markers" is a > worthwhile suggestion. > > Second, though Log4j filters are an option, I really think that's an > advanced solution that again, most users never have to deal with. Also > it's totally wasteful of cpu, having tapestry do all of this logging, > then forcing the users to run a regexp or starts with against EVERY > SINGLE log event, no matter where they came from, to discover whether to > drop the log event or not. > > let me vent for a second: > > Look, these "suggestions" for solving the "problem" are complicated or > "advanced" options, that still are not the best. The issue is still > that a low level library ( tapestry ) is hijacking my logging category > to spit out it's own debug. Thus it's really hard for me to figure out > who's actually logging, and control that... > > Yes I can do log filters, regexps, string compares, but really? Like > you said, as soon as tapestry changes their log messages, it breaks. > And you have to constantly discover what tapestry logs and why, and make > sure that your code doesn't log anything close to that ( false positives > ). It's just overly complicated and onerous to even suggest that to > your users... > > > Alright, so I think I'm done venting. Thank you for listening! :) > > But the point is.. you can always come up 10 ways to accomplish > something, and the simplest is usually the best. > > > > Tapestry should simply change their low level log points to be TRACE, or > simply change what category they log against to be clearly marked as > being logged by Tapestry, not my code. Simple. Clean. Efficient. > > > > > > > Lutz Hühnken wrote: > > Hi Fernando, > > > >> Sorry, I might be worked up, but really, wow this is just amazing me > how no > >> one has complained about this yet. > > > > well, this is just not true. You will find many discussions regarding > > this on this mailing list. > > > > Workarounds have been proposed. For log4j, you might try a filter > > > > http://www.nabble.com/T5%3A-How-to-configure-T5-not-to-display-unwanted- > log-td16024408.html > > > > (I used that in the past, but it doesn't seem to work anymore for me, > > I haven't had the time to look into that yet.) > > > > A probably better way would be to use markers, see > > https://issues.apache.org/jira/browse/TAPESTRY-2474 > > > > Log4j 1.2.x doesn't support them, though. > > > > hth, > > > > Lutz > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
