Ceki,
Here is a copy of my previous email...
Hi,
We use Log4J extensively and find that sometimes we alwayswant
to log a message, but the message is simply for
informationalpurposes. Using Logger/Category.fatal() would
potentially frightenusers, but using Logger/Category.info() may
not show up if they havereconfigured logging.
While it would be possible to save the priority for thecategory,
change the priority for the category, log the message andthen
restore the priority for the category, this seemed
veryinefficient both in terms of lines of code and run-time
performance.
So, I developed the following four (incredibly simple)methods,
which regardless of the current priority of theLogger/Category,
will always log the message. The diff is from the1.2.8 source.
I hereby donate this code to the Apache Software
Foundation.Please consider adding these methods to Log4J.
Regards,
Barry Sheward
1037a1038,1111
>
> /**
> Log a message object with the [EMAIL PROTECTED] Priority#INFOINFO}
priority
> regardless of whether <code>INFO</code> output isenabled
for
> this category.
>
> <p>This method converts the message object
> (passed as parameter) to a string by invoking
theappropriate
> [EMAIL PROTECTED] ObjectRenderer}. It then proceeds to call all the
> registered appenders in this category and also higherin
the
> hierarchy depending on the value of the additivity flag.
>
> <p><b>WARNING</b> Note that passing a [EMAIL PROTECTED] to
this
> method will print the name of the<code>Throwable</code>
but no
> stack trace. To print a stack trace use the
[EMAIL PROTECTED](Object,
> Throwable)} form instead.
>
> @param message the message object to log. */
> public
> void always(Object message) {
> forcedLog(FQCN, Priority.INFO, message, null);
> }
>
>
> /**
> Log a message object with the <code>INFO</code>priority
including
> the stack trace of the [EMAIL PROTECTED] Throwable}<code>t</code>
passed as
> parameter regardless of whether <code>INFO</code>priority
output
> is enabled for this category.
>
> <p>See [EMAIL PROTECTED] #always(Object)} form for more
detailedinformation.
>
> @param message the message object to log.
> @param t the exception to log, including its stacktrace.
*/
> public
> void always(Object message, Throwable t) {
> forcedLog(FQCN, Priority.INFO, message, t);
> }
>
> /**
> Log a message object with the specified priority
> regardless of whether the specified priority output
isenabled for
> this Category.
>
> <p>See [EMAIL PROTECTED] #always(Object)} form for more
detailedinformation.
>
> <p><b>WARNING</b> Note that passing a [EMAIL PROTECTED] to
this
> method will print the name of the<code>Throwable</code>
but no
> stack trace. To print a stack trace use the
[EMAIL PROTECTED](Object,
> Throwable)} form instead.
>
> @param message the message object to log.
> @param priority the priority to log the message at. */
> public
> void always(Object message, Priority priority) {
> forcedLog(FQCN, priority, message, null);
> }
>
>
> /**
> Log a message object with the specified priorityincluding
> the stack trace of the [EMAIL PROTECTED] Throwable}<code>t</code>
passed as
> parameter regardless of whether specified priority output
> is enabled for this Category.
>
> <p>See [EMAIL PROTECTED] #debug(Object)} form for more
detailedinformation.
>
> @param message the message object to log.
> @param t the exception to log, including its stack trace.
> @param priority the priority to log the message at. */
> public
> void always(Object message, Throwable t, Prioritypriority) {
> forcedLog(FQCN, priority, message, t);
> }
On Fri, 2004-01-30 at 15:03, Ceki G�lc� wrote:
> At 02:00 PM 1/30/2004 -0500, Barry Sheward wrote:
> >So Ceki, how would you go about trying to do what I want to do?
>
>
> >The alternative to adding four methods to Category is having to subclass
> >Level to include a new Level and use Category.log( Level, ... ) or
> >subclass Category too.
> >
> >Either approach will eventually end up with us writing wrappers around
> >Log4J, which I believe is something that you have argued against in the
> >past (http://www.qos.ch/logging/thinkAgain.html).
>
> My argument was against using commons-logging, in particular its
> classloader based discovery mechanism. I have no beef with wrapping the
> Logger class. Actually, my book lists several cases where wrapping can be
> useful as well as the pitfalls involved in wrapping the Logger class.
>
> >Are we the only ones who want this functionality?
>
> Apologies, but what functionality is that exactly?
-
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
