Re: so much useless logging
Szemere Szemere wrote: +1 for t5.enhanced For everyone who is interested in this feature and wants it in the 5.0 finale, the most effective way is to vote on Jira for it. The bug can be find here: https://issues.apache.org/jira/browse/TAP5-119 And the registration in issues.apache.org is opened. I read that as category "com.company.webapp.Page" --> "t5.enhanced.com.company.webapp.Page" I agree with you interpretation. -- Francois Armand Etudes & Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 --- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: so much useless logging
+1 for t5.enhanced I read that as category "com.company.webapp.Page" --> "t5.enhanced.com.company.webapp.Page" Szemere
Re: so much useless logging
That's my proposal as well. Simply add a prefix that is unequivocally
owned by tapestry ("t5.enhanced", etc), so that everyone (no matter what
logging system you use), can reliably and efficiently control what gets
logged and how.
Andy Pahne wrote:
I'd prefer a prefix like "t5.enhanced." for the logging category That
way I'd be in full control what comes up and what doesn't.
Jonathan Barker wrote:
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]
-
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]
Re: so much useless logging
I'd prefer a prefix like "t5.enhanced." for the logging category That way I'd be in full control what comes up and what doesn't. Jonathan Barker wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: so much useless logging
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]
Re: so much useless logging
On Wed, Oct 22, 2008 at 7:56 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > Most people use Log4j, so I don't think suggesting "Markers" is a worthwhile > suggestion. I've switched to logback from log4j on a small project with high concurrent utilization and besides the nice new features i've found quite a huge speed improvements. The application is particular since it has just two pages which are used by other application for data crunching so it has to provide high concurrency and high speed "answers" on that small subset of operations but logback does has helped. The funny thing is that I've chosen to change logging implementation just to see how it works. Just for the records. -- Massimo http://meridio.blogspot.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: so much useless logging
Lutz Hühnken schrieb: 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.) stopped working for me, too. 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: so much useless logging
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]
Re: so much useless logging
sorry. nope. the log that I included did not include the generated class code. And I hit my Start page a few times to make sure I wasn't mad either. The log I included is being spit out for every single request of my Start page! Toby Hobson wrote: I agree that this is a little annoying but it only happens when the page is first loaded, subsequent requests will generate "cleaner" debug statements Toby 2008/10/18 Fernando Padilla <[EMAIL PROTECTED]> alright, so we just upgraded from 5.0.11 to 5.0.16-SNAPSHOT, so sorry I was not able to complain earlier.. Please help: but tapestry is just spewing TONS of debug, that I still don't see any easy way to turn off. Please help, this is just ridiculous! First the contribution system is broken not allowing us to override defaults, then the debug is so superfluous that it's just so bad! below is an example of rendering my Start page.. ONE page request. REALLY! Sorry, I might be worked up, but really, wow this is just amazing me how no one has complained about this yet. And the issue is that we want debug turned on for OUR code (in development and production), NOT low level tapestry code that we trust. But tapestry uses the same category as our classes, so there is NO easy way to filter that out using log4j.properties. I know that people said before that we can setup fancy filter to match and filter out some log entries. But these many log entries are just ridiculous. And how am I supposed to filter against "Invoking: " that's just such a broad filter term. Users of tapestry should not be forced to jump through so many hoops! I want: Tapestry MUST change the categories it logs against, so that they DO NOT match the pages ( tapestry.site.PAGECLASS ) or it SHOULD allow me to turn off all of this logging using a config setting.. Or I will have to maintain our own build of tapestry to fix this ourselves.. crazy. what do you think?? is this your pet peeve too?? --- Debug output for a single rendering of my Start page: 2008-10-17 16:48:37,802 [btpool0-2] DEBUG com.protrade.fanwars.base.pages.Start - Dispatch event: ComponentEvent[activate from (self)] 2008-10-17 16:48:37,802 [btpool0-2] DEBUG com.protrade.fanwars.base.pages.Start - Invoking: com.protrade.fanwars.base.pages.Start.setupRender() (at Start.java:42) 2008-10-17 16:48:37,806 [btpool0-2] DEBUG com.protrade.fanwars.base.components.CanvasLayout - Invoking: com.protrade.fanwars.base.components.CanvasLayout.beginRender() (at CanvasLayout.java:19) 2008-10-17 16:48:37,808 [btpool0-2] DEBUG com.protrade.unifiedsocial.tapestry.components.MakePageLinksAbsolute - Invoking: com.protrade.unifiedsocial.tapestry.components.MakePageLinksAbsolute.beginRender() (at MakePageLinksAbsolute.java:25) 2008-10-17 16:48:37,808 [btpool0-2] DEBUG com.protrade.facebook.base.components.layout.LayoutDocFlex - Invoking: com.protrade.facebook.base.components.layout.LayoutDocFlex.setupRender() (at LayoutDocFlex.java:25) 2008-10-17 16:48:37,808 [btpool0-2] DEBUG com.protrade.facebook.base.components.layout.LayoutDocFlex - Invoking: com.protrade.facebook.base.components.layout.LayoutDocBase.beginRender() (at LayoutDocBase.java:47) 2008-10-17 16:48:37,808 [btpool0-2] DEBUG com.protrade.tapestry5.base.components.layout.LayoutIslandAdLeader - Invoking: com.protrade.tapestry5.base.components.layout.LayoutIslandAdLeader.beginRender(org.apache.tapestry5.MarkupWriter) (at LayoutIslandAdLeader.java:20) 2008-10-17 16:48:37,808 [btpool0-2] DEBUG com.protrade.fanwars.base.components.ads.AdsFanwarsGamSlot - Invoking: com.protrade.fanwars.base.components.ads.AdsFanwarsGamSlot.setupRender() (at AdsFanwarsGamSlot.java:76) 2008-10-17 16:48:37,808 [btpool0-2] DEBUG com.protrade.facebook.base.components.ads.AdsGamSlotIframe - Invoking: com.protrade.facebook.base.components.ads.AdsGamSlotIframe.beginRender(org.apache.tapestry5.MarkupWriter) (at AdsGamSlotIframe.java:34) 2008-10-17 16:48:37,809 [btpool0-2] DEBUG com.protrade.facebook.base.components.ads.AdsGamSlotIframe - Invoking: com.protrade.facebook.base.components.ads.AdsGamSlotIframe.afterRender(org.apache.tapestry5.MarkupWriter) (at AdsGamSlotIframe.java:60) 2008-10-17 16:48:37,809 [btpool0-2] DEBUG com.protrade.tapestry5.base.components.layout.LayoutIslandAdLeader - Invoking: com.protrade.tapestry5.base.components.layout.LayoutIslandAdLeader.afterRender(org.apache.tapestry5.MarkupWriter) (at LayoutIslandAdLeader.java:30) 2008-10-17 16:48:37,813 [btpool0-2] DEBUG com.protrade.fanwars.base.components.team.TeamLogo - Invoking: com.protrade.fanwars.base.components.team.TeamLogo.setupRender() (at TeamLogo.java:56) 2008-10-17 16:48:37,814 [btpool0-2] DEBUG com.protrade.fanwars.base.components.team.TeamLogo - Invoking: com.protrade.fanwars.base.components.team.TeamLogo.beginRender(org.apache.tapestry5.MarkupWriter) (at TeamLogo.java:81) 2008-10-17 16:48:37,814 [btpool0-2] DEBUG com.protrade.fanwars.base.components.team.TeamLogo - Invoking: com
Re: so much useless logging
There is a JIRA issue about this: https://issues.apache.org/jira/browse/TAP5-119 Please vote, so we get it higher on priority list. Fernando Padilla wrote: alright, so we just upgraded from 5.0.11 to 5.0.16-SNAPSHOT, so sorry I was not able to complain earlier.. Please help: but tapestry is just spewing TONS of debug, that I still don't see any easy way to turn off. Please help, this is just ridiculous! First the contribution system is broken not allowing us to override defaults, then the debug is so superfluous that it's just so bad! below is an example of rendering my Start page.. ONE page request. REALLY! Sorry, I might be worked up, but really, wow this is just amazing me how no one has complained about this yet. And the issue is that we want debug turned on for OUR code (in development and production), NOT low level tapestry code that we trust. But tapestry uses the same category as our classes, so there is NO easy way to filter that out using log4j.properties. I know that people said before that we can setup fancy filter to match and filter out some log entries. But these many log entries are just ridiculous. And how am I supposed to filter against "Invoking: " that's just such a broad filter term. Users of tapestry should not be forced to jump through so many hoops! I want: Tapestry MUST change the categories it logs against, so that they DO NOT match the pages ( tapestry.site.PAGECLASS ) or it SHOULD allow me to turn off all of this logging using a config setting.. Or I will have to maintain our own build of tapestry to fix this ourselves.. crazy. what do you think?? is this your pet peeve too?? --- Debug output for a single rendering of my Start page: 2008-10-17 16:48:37,802 [btpool0-2] DEBUG com.protrade.fanwars.base.pages.Start - Dispatch event: ComponentEvent[activate from (self)] 2008-10-17 16:48:37,802 [btpool0-2] DEBUG com.protrade.fanwars.base.pages.Start - Invoking: com.protrade.fanwars.base.pages.Start.setupRender() (at Start.java:42) 2008-10-17 16:48:37,806 [btpool0-2] DEBUG com.protrade.fanwars.base.components.CanvasLayout - Invoking: com.protrade.fanwars.base.components.CanvasLayout.beginRender() (at CanvasLayout.java:19) 2008-10-17 16:48:37,808 [btpool0-2] DEBUG com.protrade.unifiedsocial.tapestry.components.MakePageLinksAbsolute - Invoking: com.protrade.unifiedsocial.tapestry.components.MakePageLinksAbsolute.beginRender() (at MakePageLinksAbsolute.java:25) 2008-10-17 16:48:37,808 [btpool0-2] DEBUG com.protrade.facebook.base.components.layout.LayoutDocFlex - Invoking: com.protrade.facebook.base.components.layout.LayoutDocFlex.setupRender() (at LayoutDocFlex.java:25) 2008-10-17 16:48:37,808 [btpool0-2] DEBUG com.protrade.facebook.base.components.layout.LayoutDocFlex - Invoking: com.protrade.facebook.base.components.layout.LayoutDocBase.beginRender() (at LayoutDocBase.java:47) 2008-10-17 16:48:37,808 [btpool0-2] DEBUG com.protrade.tapestry5.base.components.layout.LayoutIslandAdLeader - Invoking: com.protrade.tapestry5.base.components.layout.LayoutIslandAdLeader.beginRender(org.apache.tapestry5.MarkupWriter) (at LayoutIslandAdLeader.java:20) 2008-10-17 16:48:37,808 [btpool0-2] DEBUG com.protrade.fanwars.base.components.ads.AdsFanwarsGamSlot - Invoking: com.protrade.fanwars.base.components.ads.AdsFanwarsGamSlot.setupRender() (at AdsFanwarsGamSlot.java:76) 2008-10-17 16:48:37,808 [btpool0-2] DEBUG com.protrade.facebook.base.components.ads.AdsGamSlotIframe - Invoking: com.protrade.facebook.base.components.ads.AdsGamSlotIframe.beginRender(org.apache.tapestry5.MarkupWriter) (at AdsGamSlotIframe.java:34) 2008-10-17 16:48:37,809 [btpool0-2] DEBUG com.protrade.facebook.base.components.ads.AdsGamSlotIframe - Invoking: com.protrade.facebook.base.components.ads.AdsGamSlotIframe.afterRender(org.apache.tapestry5.MarkupWriter) (at AdsGamSlotIframe.java:60) 2008-10-17 16:48:37,809 [btpool0-2] DEBUG com.protrade.tapestry5.base.components.layout.LayoutIslandAdLeader - Invoking: com.protrade.tapestry5.base.components.layout.LayoutIslandAdLeader.afterRender(org.apache.tapestry5.MarkupWriter) (at LayoutIslandAdLeader.java:30) 2008-10-17 16:48:37,813 [btpool0-2] DEBUG com.protrade.fanwars.base.components.team.TeamLogo - Invoking: com.protrade.fanwars.base.components.team.TeamLogo.setupRender() (at TeamLogo.java:56) 2008-10-17 16:48:37,814 [btpool0-2] DEBUG com.protrade.fanwars.base.components.team.TeamLogo - Invoking: com.protrade.fanwars.base.components.team.TeamLogo.beginRender(org.apache.tapestry5.MarkupWriter) (at TeamLogo.java:81) 2008-10-17 16:48:37,814 [btpool0-2] DEBUG com.protrade.fanwars.base.components.team.TeamLogo - Invoking: com.protrade.fanwars.base.components.team.TeamLogo.afterRender(org.apache.tapestry5.MarkupWriter) (at TeamLogo.java:88) 2008-10-17 16:48:37,814 [btpool0-2] DEBUG com.protrade.fanwars.base.components.nav.NavListFanwars - Invoking: com.protrade
Re: so much useless logging
I agree that this is a little annoying but it only happens when the page is first loaded, subsequent requests will generate "cleaner" debug statements Toby 2008/10/18 Fernando Padilla <[EMAIL PROTECTED]> > alright, so we just upgraded from 5.0.11 to 5.0.16-SNAPSHOT, so sorry I was > not able to complain earlier.. Please help: > > but tapestry is just spewing TONS of debug, that I still don't see any easy > way to turn off. Please help, this is just ridiculous! First the > contribution system is broken not allowing us to override defaults, then the > debug is so superfluous that it's just so bad! > > > below is an example of rendering my Start page.. ONE page request. REALLY! > Sorry, I might be worked up, but really, wow this is just amazing me how no > one has complained about this yet. > > And the issue is that we want debug turned on for OUR code (in development > and production), NOT low level tapestry code that we trust. But tapestry > uses the same category as our classes, so there is NO easy way to filter > that out using log4j.properties. I know that people said before that we can > setup fancy filter to match and filter out some log entries. But these many > log entries are just ridiculous. And how am I supposed to filter against > "Invoking: " that's just such a broad filter term. Users of tapestry > should not be forced to jump through so many hoops! > > > > I want: > Tapestry MUST change the categories it logs against, so that they DO NOT > match the pages ( tapestry.site.PAGECLASS ) or it SHOULD allow me to turn > off all of this logging using a config setting.. Or I will have to maintain > our own build of tapestry to fix this ourselves.. crazy. > > > > > what do you think?? is this your pet peeve too?? > > > > > > > --- > Debug output for a single rendering of my Start page: > > 2008-10-17 16:48:37,802 [btpool0-2] DEBUG > com.protrade.fanwars.base.pages.Start - Dispatch event: > ComponentEvent[activate from (self)] > 2008-10-17 16:48:37,802 [btpool0-2] DEBUG > com.protrade.fanwars.base.pages.Start - Invoking: > com.protrade.fanwars.base.pages.Start.setupRender() (at Start.java:42) > 2008-10-17 16:48:37,806 [btpool0-2] DEBUG > com.protrade.fanwars.base.components.CanvasLayout - Invoking: > com.protrade.fanwars.base.components.CanvasLayout.beginRender() (at > CanvasLayout.java:19) > 2008-10-17 16:48:37,808 [btpool0-2] DEBUG > com.protrade.unifiedsocial.tapestry.components.MakePageLinksAbsolute - > Invoking: > com.protrade.unifiedsocial.tapestry.components.MakePageLinksAbsolute.beginRender() > (at MakePageLinksAbsolute.java:25) > 2008-10-17 16:48:37,808 [btpool0-2] DEBUG > com.protrade.facebook.base.components.layout.LayoutDocFlex - Invoking: > com.protrade.facebook.base.components.layout.LayoutDocFlex.setupRender() (at > LayoutDocFlex.java:25) > 2008-10-17 16:48:37,808 [btpool0-2] DEBUG > com.protrade.facebook.base.components.layout.LayoutDocFlex - Invoking: > com.protrade.facebook.base.components.layout.LayoutDocBase.beginRender() (at > LayoutDocBase.java:47) > 2008-10-17 16:48:37,808 [btpool0-2] DEBUG > com.protrade.tapestry5.base.components.layout.LayoutIslandAdLeader - > Invoking: > com.protrade.tapestry5.base.components.layout.LayoutIslandAdLeader.beginRender(org.apache.tapestry5.MarkupWriter) > (at LayoutIslandAdLeader.java:20) > 2008-10-17 16:48:37,808 [btpool0-2] DEBUG > com.protrade.fanwars.base.components.ads.AdsFanwarsGamSlot - Invoking: > com.protrade.fanwars.base.components.ads.AdsFanwarsGamSlot.setupRender() (at > AdsFanwarsGamSlot.java:76) > 2008-10-17 16:48:37,808 [btpool0-2] DEBUG > com.protrade.facebook.base.components.ads.AdsGamSlotIframe - Invoking: > com.protrade.facebook.base.components.ads.AdsGamSlotIframe.beginRender(org.apache.tapestry5.MarkupWriter) > (at AdsGamSlotIframe.java:34) > 2008-10-17 16:48:37,809 [btpool0-2] DEBUG > com.protrade.facebook.base.components.ads.AdsGamSlotIframe - Invoking: > com.protrade.facebook.base.components.ads.AdsGamSlotIframe.afterRender(org.apache.tapestry5.MarkupWriter) > (at AdsGamSlotIframe.java:60) > 2008-10-17 16:48:37,809 [btpool0-2] DEBUG > com.protrade.tapestry5.base.components.layout.LayoutIslandAdLeader - > Invoking: > com.protrade.tapestry5.base.components.layout.LayoutIslandAdLeader.afterRender(org.apache.tapestry5.MarkupWriter) > (at LayoutIslandAdLeader.java:30) > 2008-10-17 16:48:37,813 [btpool0-2] DEBUG > com.protrade.fanwars.base.components.team.TeamLogo - Invoking: > com.protrade.fanwars.base.components.team.TeamLogo.setupRender() (at > TeamLogo.java:56) > 2008-10-17 16:48:37,814 [btpool0-2] DEBUG > com.protrade.fanwars.base.components.team.TeamLogo - Invoking: > com.protrade.fanwars.base.components.team.TeamLogo.beginRender(org.apache.tapestry5.MarkupWriter) > (at TeamLogo.java:81) > 2008-10-17 16:48:37,814 [btpool0-2] DEBUG > com.protrade.fanwars.base.components.team.TeamLogo - Invoking: > com.protrade.fanwars.base.components.team.TeamLogo.afterRender(org.apache.tapest
