You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by David Owens <do...@synxis.com> on 2001/06/22 17:29:07 UTC
LogLog.isEnabledFor()
All,
LogLog is a very cool thing, and allows a central, standard way
to log messages from withing log4j components. However, it seems
that it lacks the standard Category behavior which allows checking
of logging priority. This functionality should be included so
logging lines which do string concatination could be guarded by
tests for that priority level. In other words:
The innefecient line:
LogLog.debug("The value was: " + myValue.toSting() + " and " +
foo.value1);
would be guarded like this:
if(LogLog.isEnabledFor(Priority.DEBUG))
{
LogLog.debug("The value was: " + myValue.toSting() + " and " +
foo.value1);
}
Any one else have thoughts on this? Perhaps LogLog should just be a
special
subclass of Category....
I would be happy to submit some modifications like this, but I thought I
would
bounce it off here first.
|)ave
Re: LogLog.isEnabledFor()
Posted by David Owens <do...@synxis.com>.
I agree, we don't need to over complicate it... unless in the future
people want/need more flexability. Your suggestion is more along
what I was thinking about, however, those attributes are private
and protected, so I wasn't sure if we wanted to access them directly
or create methods.
|)ave
Anders Kristensen wrote:
> Well, it still only matters if it's invoked a *lot*, e.g. on the main
> path of a Category or some appender or layout. *If* this is the case
> then I would agree we should do something about it, although I don't
> think it should be something as complete as log4j itself. Just moving
> the check done in LogLog.debug, say, itself up to guard the invocation
> would do it, e.g. change
>
> LogLog.error(...);
>
> to
>
> if (!LogLog.quietMode) LogLog.error(...);
>
> Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: LogLog.isEnabledFor()
Posted by Anders Kristensen <ak...@dynamicsoft.com>.
Well, it still only matters if it's invoked a *lot*, e.g. on the main
path of a Category or some appender or layout. *If* this is the case
then I would agree we should do something about it, although I don't
think it should be something as complete as log4j itself. Just moving
the check done in LogLog.debug, say, itself up to guard the invocation
would do it, e.g. change
LogLog.error(...);
to
if (!LogLog.quietMode) LogLog.error(...);
Anders
David Owens wrote:
>
> I agree, however, the code is always executed regardless of if the
> debugging actually results in output or not. So, as a result, you
> end up creating and concatinating Strings etc for no output.
>
> |)ave
>
> Anders Kristensen wrote:
>
> > LogLog is only intended to be invoked sparingly, e.g. during
> > configuration for debugging or when something goes wrong internally in
> > log4j. This means it doesn't have to be as fast as regular logging.
> >
> > Anders
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: LogLog.isEnabledFor()
Posted by David Owens <do...@synxis.com>.
I agree, however, the code is always executed regardless of if the
debugging actually results in output or not. So, as a result, you
end up creating and concatinating Strings etc for no output.
|)ave
Anders Kristensen wrote:
> LogLog is only intended to be invoked sparingly, e.g. during
> configuration for debugging or when something goes wrong internally in
> log4j. This means it doesn't have to be as fast as regular logging.
>
> Anders
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: LogLog.isEnabledFor()
Posted by Anders Kristensen <ak...@dynamicsoft.com>.
LogLog is only intended to be invoked sparingly, e.g. during
configuration for debugging or when something goes wrong internally in
log4j. This means it doesn't have to be as fast as regular logging.
Anders
David Owens wrote:
>
> All,
>
> LogLog is a very cool thing, and allows a central, standard way
> to log messages from withing log4j components. However, it seems
> that it lacks the standard Category behavior which allows checking
> of logging priority. This functionality should be included so
> logging lines which do string concatination could be guarded by
> tests for that priority level. In other words:
>
> The innefecient line:
> LogLog.debug("The value was: " + myValue.toSting() + " and " +
> foo.value1);
>
> would be guarded like this:
> if(LogLog.isEnabledFor(Priority.DEBUG))
> {
> LogLog.debug("The value was: " + myValue.toSting() + " and " +
> foo.value1);
> }
>
> Any one else have thoughts on this? Perhaps LogLog should just be a
> special
> subclass of Category....
>
> I would be happy to submit some modifications like this, but I thought I
> would
> bounce it off here first.
>
> |)ave
>
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org