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 Rodrigo de Salvo Braz <ro...@yahoo.com> on 2003/05/23 08:52:51 UTC

Hierarchical logging

Hi,

I am new to this list, so excuse me if I bring up
something already discussed...

I have written a subclass of Logger that manages logs
with varying levels of detail, in a hierarchical
manner, and two different ways of visualizing them. I
found this to be invaluable for my debugging and I use
it all the time, so I am writing to ask if there is
interest in including this in log4j and how I could go
about it.

It is far from being something that can be readily
incorporated to the product, but it is a start.

You can read more about it, including an example and
screenshots, at
http://l2r.cs.uiuc.edu/~braz/detaillogging.html

Thanks,

Rodrigo

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org


Re: Hierarchical logging

Posted by Rodrigo de Salvo Braz <ro...@yahoo.com>.
--- Ceki G�lc� <ce...@qos.ch> wrote:
> At 06:18 PM 5/23/2003 -0700, Rodrigo de Salvo Braz
> wrote:
> >* Info at level 1
> >********* Info at level 9
> The result still shows correct indentation levels.
> The fact that
> indentation levels 2-8 are empty should not matter.
> Or?

As I said, it only matters for the waste of columns,
but this is not really important in the long term.

> The plan is you and you subsume the plan. It is what
> you thought the plan
> was in the past, what you think the plan is
> currently, what you will
> think the plan will be in the future. When you think
> about what you
> might think the plan would be, that's still the
> plan.

That makes me feel very powerful :-) I guess I have
some homework to do (don't know much about MDC).

Thanks,

Rodrigo

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org


Re: Hierarchical logging

Posted by Ceki Gülcü <ce...@qos.ch>.
At 06:18 PM 5/23/2003 -0700, Rodrigo de Salvo Braz wrote:
>--- Ceki Gülcü <ce...@qos.ch> wrote:
>
>It is a good point, but suppose that detail level 1 is
>DEBUG, then detail levels from 2 to 8 are INFO, and 9
>is DEBUG again. If the logger is at DEBUG level, we
>would have
>
>* Info at level 1
>********* Info at level 9
>
>wasting space for markers. This may be a problem if
>you are actually showing the markers, as in the Emacs
>visualization, although at some point people should be
>using better visualizers anyway.

The result still shows correct indentation levels. The fact that
indentation levels 2-8 are empty should not matter. Or?

> >    MDC.incIndentationLevel();
> >    logger.debug("Calculating all products from
> > list.");
> >    logger.debug("do some logging.");
> >    logger.debug(Got all products of list.");
> >    MDC.decIndentationLevel();
> >
> > We can leverage the existing log4j infrastructure
> > with almost no
> > structural changes and still provide the same
> > service as the
> > DetailLogger class.
>
>I agree that this is the best solution, but it
>requires either extending MDC with or subclassing it
>for that functionality (if subclassing MDC is possible
>and advisable). It would probably require other
>methods also, for logging collections or setting
>options. Instead of leaving this for each user to do,
>it would be better to have as a class in log4j. The
>standardization would also favor things like having
>Chainsaw to have the option of nesting visualization
>at some point, with very little user setup.

This is the kind of functionality that we would like to
support within the log4j core. If we need to extend the MDC class to
do that, then that's what we will do.

>Are there any plans in that regard? I would like to
>help.

The plan is you and you subsume the plan. It is what you thought the plan
was in the past, what you think the plan is currently, what you will
think the plan will be in the future. When you think about what you
might think the plan would be, that's still the plan.

>Thanks,
>
>Rodrigo

--
Ceki  For log4j documentation consider "The complete log4j manual"
       ISBN: 2970036908  http://www.qos.ch/shop/products/clm_t.jsp 


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org


Re: Hierarchical logging

Posted by Rodrigo de Salvo Braz <ro...@yahoo.com>.
--- Ceki G�lc� <ce...@qos.ch> wrote:

> 2) I think you can get rid of the Detail class
> altogether. The step
> variable does not seem to be really used or useful.

True. I guess I had some generality in mind that never
came.

> Consider what would happen if you did not go through
> the exercise of
> checking whether indent() is really necessary. You
> would indent, log
> nothing and some time later unindent. The
> superfluous indent/unindent
> would not be visible since there was no logging
> output. This goes to
> show you that the
> l.isGreaterOrEqual(getEffectiveLevel()) check is not
> that important.

It is a good point, but suppose that detail level 1 is
DEBUG, then detail levels from 2 to 8 are INFO, and 9
is DEBUG again. If the logger is at DEBUG level, we
would have

* Info at level 1
********* Info at level 9

wasting space for markers. This may be a problem if
you are actually showing the markers, as in the Emacs
visualization, although at some point people should be
using better visualizers anyway.

>    MDC.incIndentationLevel();
>    logger.debug("Calculating all products from
> list.");
>    logger.debug("do some logging.");
>    logger.debug(Got all products of list.");
>    MDC.decIndentationLevel();
> 
> We can leverage the existing log4j infrastructure
> with almost no
> structural changes and still provide the same
> service as the
> DetailLogger class.

I agree that this is the best solution, but it
requires either extending MDC with or subclassing it
for that functionality (if subclassing MDC is possible
and advisable). It would probably require other
methods also, for logging collections or setting
options. Instead of leaving this for each user to do,
it would be better to have as a class in log4j. The
standardization would also favor things like having
Chainsaw to have the option of nesting visualization
at some point, with very little user setup.

Are there any plans in that regard? I would like to
help.

Thanks,

Rodrigo

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org


Re: Hierarchical logging

Posted by Ceki Gülcü <ce...@qos.ch>.
Although not completely original, this is the kind of idea which, if
cultivated properly, can go quite far. A Belgian developer had C++
code that would mark start of logging operations and later mark their
end. If in between there were no errors then logs would just be
forgotten but in case of errors logging details would appear in full
detail.

Here are some remarks on your specific implementation:

1) Sub-classing Logger should not be use to change the user interface
of loggers. Sub-classing is inappropriate if the derived class
modifies, adds or removes methods found in the Logger class. In this
case, wrapping Logger would have been safer. If you are interested in
the details of why and how, then you should consider buying my book.

2) I think you can get rid of the Detail class altogether. The step
variable does not seem to be really used or useful. The level variable
is more interesting. If I understand correctly, you use the level to
determine if an indent operation is required following a beginDetail
method call. You also push the "detail" on to a stack so that it can
be retrieved and used to determine whether an unindent operation is
needed following an endDetail method call.

Consider what would happen if you did not go through the exercise of
checking whether indent() is really necessary. You would indent, log
nothing and some time later unindent. The superfluous indent/unindent
would not be visible since there was no logging output. This goes to
show you that the l.isGreaterOrEqual(getEffectiveLevel()) check is not
that important.

If we forget about the Detail class, then the indentation level is
only tracked by the detailLevel variable. If you think about it, we can
go a step further and remove indentation tracking from the logger
class and place it somewhere else. But where? In o.a.l.MDC and NDC
classes the keyword is "diagnostic context". What your indentation is
doing is providing context to log operations. Thus,

   logger.startDetail("Calculating all products from list.");
   logger.debug("do some logging."
   logger.endDetail("Got all products of list.");

can be replaced by

   MDC.incIndentationLevel();
   logger.debug("Calculating all products from list.");
   logger.debug("do some logging.");
   logger.debug(Got all products of list.");
   MDC.decIndentationLevel();

We can leverage the existing log4j infrastructure with almost no
structural changes and still provide the same service as the
DetailLogger class.

Cheers,

At 11:52 PM 5/22/2003 -0700, you wrote:
>Hi,
>
>I am new to this list, so excuse me if I bring up
>something already discussed...
>
>I have written a subclass of Logger that manages logs
>with varying levels of detail, in a hierarchical
>manner, and two different ways of visualizing them. I
>found this to be invaluable for my debugging and I use
>it all the time, so I am writing to ask if there is
>interest in including this in log4j and how I could go
>about it.
>
>It is far from being something that can be readily
>incorporated to the product, but it is a start.
>
>You can read more about it, including an example and
>screenshots, at
>http://l2r.cs.uiuc.edu/~braz/detaillogging.html
>
>Thanks,
>
>Rodrigo

--
Ceki  For log4j documentation consider "The complete log4j manual"
       ISBN: 2970036908  http://www.qos.ch/shop/products/clm_t.jsp 


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org