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]

Reply via email to