I don't know the history on why the loggers/listeners are setup the way that they are, but I find it quite useful to have different listeners operating at different logging levels.
I could see a scenario where the listeners/loggers register their logging level with the runtime such that the runtime could at least do partial filtering for the levels that no registered listener cares about. This could even be dynamic if the listeners need to change during the course of execution.
JEC
| ____________________________________________________________________________________________ | |
| Jeffrey E. (Jeff) Care | |
| IBM WebSphere Application Server Development |
WAS Pyxis Lead
Release Engineer
|
|
| |
"Scott Stirling" <[EMAIL PROTECTED]> wrote on 09/25/2006 10:33:43 AM:
> Ah, that adds some helpful context.
>
> How come the runtime doesn't know the current log level?
>
> Scott Stirling
> Framingham, MA
>
> On 9/25/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Because the runtime does not know the current loglevel.
> > The RT forwards the (build) message to the registered Listeners.
> >
> > Jan
> >
> > >-----Ursprüngliche Nachricht-----
> > >Von: Scott Stirling [mailto:[EMAIL PROTECTED]
> > >Gesendet: Montag, 25. September 2006 15:29
> > >An: Ant Developers List
> > >Betreff: Re: Ant log statements being created even when not used
> > >
> > >What's wrong with a guard statement that doesn't construct the
> > >log message unless the log level at which the message is used
> > >is enabled?
> > >
> > >i.e.:
> > >
> > >if (LOG.isDebugEnabled()) {
> > > StringBuilder msg = new StringBuilder();
> > > msg.append(etc....);
> > > [...]
> > > LOG.debug(msg.toString());
> > >}
> > >
> > >That's simple, don't you think? In my experience, the problem
> > >of polluting "client" code with logging is a red herring and
> > >not such a problem. More common are the problems of not enough
> > >useful logging or too much logging, e.g., when every component
> > >in an application stack is coded to log the same damn thing so
> > >you wind up with massive stack traces logged multiple times by
> > >well-meaning components that should often just be throwing
> > >their exceptions up to a higher layer for logging and other handling.
> > >
> > >
> > >Scott Stirling
> > >Framingham, MA
> > >
> > >On 9/25/06, Kevin Jackson <[EMAIL PROTECTED]> wrote:
> > >> Hi,
> > >> Remember early this year I had a problem with a build that basically
> > >> ran out of memory and if I commented out logging code I could get it
> > >> to run?
> > >>
> > >> http://www.digitalmars.com/d/lazy-evaluation.html
> > >>
> > >> This explains exactly the problem (and a solution for D), I
> > >wonder if
> > >> some solution exists for Java such that log statements are not as
> > >> wasteful of resources as they currently are
> > >>
> > >> Kev
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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]
>
