tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Chaffee <g...@edamame.stinky.com>
Subject Re: Per-component logging
Date Wed, 05 Jul 2000 10:53:25 GMT

OK, I'll hold off on changing the way debug messages work until we
understand it better.

On Tue, Jul 04, 2000 at 08:30:11PM -0700, Costin Manolache wrote:
> > Component code can send all the regular verbosity levels, like ERROR,
> > WARN, INFORMATION, DEBUG.
> 
> The problem is that we don't have only 4 levels for components - the
> request
> mapper have multiple grades of debug info, and this direction ( debug
> level)
> is wrong - take a look at sendmail or squid for example.

In my proposal, this is done by having each component have as many
levels as they want, *inside* debug.


> We need to be able to turn on/off ( eventually at runtime ) individual
> component.subcomponent debugging. ( mapper/request_parser,
> mapper_prefixMap).

Check.


> The current scheme works good enough for it's goal ( debugging),
> and we should change it only if we have a complete ( and better )
> solution.

I don't want to change it, exactly.  Just clarify how it works, so we
can clearly distinguish between messages that absolutely must get
shown, messages that may be interesting to the user, and messages that
only a debugger ould love.


> All "official" logs should use the Logger, and that should include
> ERROR, WARN, INFO ( even ERROR > INFO is bad - most
> people would like to be able to disable some types of errors,
> but keep INFO).
> 
> What about just removing the ERROR/WARN/INFO/DEBUG and separate
> the "log" from "debug" ?

Hmm, I'm actually inclined towards this. Or maybe error/log/debug.


> > That means that if you want spew-level output for component Foo, which
> > outputs to "tc_log", you must (a) set the "debug" attribute for Foo to
> > 9 or 99 or whatever, and (b) set the "verbosityLevel" of the "tc_log"
> > Logger object to "DEBUG".
> 
> Why not let Foo control it's own debug ?

That's exactly what I want.

We could also say, if Foo prints a debug message, it also forcibly
sets the verbosity level of the target log to DEBUG.  A little weird
but perfectly reasonable.


> And BTW, what is the meaning of "debug" in the logger after all , and who
> will use it in this case ?

It's just a filter.  DEBUG tells the Logger to print all messages from
all components.  Then each component is only going to output the debug
messages it thinks are appropriate, based on its internal "debug"
level.

I'm not convinced this is the right design, of course.  Let's keep
thinking about it.



> Sorry, I would rather keep the current system till we have a complete
> solution.
> Right now we don't even know exactly what we want from the debug
> system. I like the timestamp changes and I think logger is in a better
> shape
> and we can have a clean and nice solution, but leave the debugger out.
> 
> That will also simplify the logger. The debugger may use the Log object
> as a tool, but it will be loose till we have a clear image of what we
> need.

Good point.


> 
> > In other words, the component would have first crack, but the Logger
> > has ultimate veto.  That way you can easily crank down the verbosity
> > level globally, or set the Logger setting to DEBUG, in which case all
> > components will be allowed to speak, but only the components you've
> > set the "debug" attribute on will want to.
> >
> > It's really quite simple :-)
> 
> I don't think we are ready for that.
> 
> I'm -1 on changing too much the debug system, I depend on it and
> I would like a better solution ( even if that will be later ).
> 
> Costin
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

-- 
Alex Chaffee                       mailto:alex@jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/

Mime
View raw message