--- Ceki Gülcü <[EMAIL PROTECTED]> wrote:
> At 15:23 15.08.2001 -0700, Morgan Delagrange wrote:
>
> >--- Ceki Gülcü <[EMAIL PROTECTED]> wrote:
> >> Hi Morgan,
> >>
> >> I think the logging proposal nicely solves the
> >> log4j.jar dependency
> >> problem. It also offers a simple logging
> interface
> >> but as you will
> >> soon discover people will want more. They will
> say,
> >> log4j supports
> >> Nested Diagnostic Contexts, your abstraction does
> >> not. Can you please add
> >> that? Oh, by the way, I also like to have Mapped
> >> Diagnostic Contexts,
> >> can you please add that to your abstraction?
> >
> >Well, first I'd go to the Log4J docs and find out
> what
> >the hell they were talking about. ;)
> >
> >> Sorry,
> >> but Mapped
> >> Diagnostic Contexts require log4j version 1.2.
> What
> >> do you to then?
> >
> >I think we're trying to find a minimal interface
> that
> >could be commonly supported. LogKit and JDK 1.4
> won't
> >have a notion of a Mapped Diagnostic Context, so it
> >wouldn't be appropriate for the abstraction layer.
> If
> >you have a need for very specific features of a
> >logging API, of course you would need to bind
> directly
> >to it.
>
> Hello Morgan,
>
> Actually LogKit has a notion of both NDCs as well as
> MDCs. They are
> called ContextStacks and ContextMaps if I am not
> mistaken.
>
> Mapped Diagnostic Contexts are just like Nested
> Diagnostic Contexts
> except that they are based on a Map instead of a
> Stack. Here is what
> the log4j manual has to say about NDC.
>
> Nested Diagnostic Contexts
>
> Most real-world systems have to deal with multiple
> clients
> simultaneously. In a typical multithreaded
> implementation of such a
> system, different threads will handle different
> clients. Logging is
> especially well suited to trace and debug complex
> distributed
> applications. A common approach to differentiate the
> logging output of
> one client from another is to instantiate a new
> separate category for
> each client. This promotes the proliferation of
> categories and
> increases the management overhead of logging.
>
> A lighter technique is to uniquely stamp each log
> request initiated
> from the same client interaction. Neil Harrison
> described this method
> in the book "Patterns for Logging Diagnostic
> Messages," in Pattern
> Languages of Program Design 3, edited by R. Martin,
> D. Riehle, and
> F. Buschmann (Addison-Wesley, 1997).
>
> To uniquely stamp each request, the user pushes
> contextual information
> into the NDC, the abbreviation of Nested Diagnostic
> Context. The NDC
> class is shown below.
>
> public class NDC {
> // Used when printing the diagnostic
> public static String get();
>
> // Remove the top of the context from the NDC.
> public static String pop();
>
> // Add diagnostic context for the current
> thread.
> public static void push(String message);
>
> // Remove the diagnostic context for this
> thread.
> public static void remove();
> }
>
> The NDC is managed per thread as a stack of
> contextual
> information. Note that all methods of the
> org.apache.log4j.NDC class
> are static. Assuming that NDC printing is turned on,
> every time a log
> request is made, the appropriate log4j component
> will include the
> entire NDC stack for the current thread in the log
> output. This is
> done without the intervention of the user, who is
> responsible only for
> placing the correct information in the NDC by using
> the push and pop
> methods at a few well-defined points in the code. In
> contrast, the
> per-client category approach commands extensive
> changes in the code.
>
> To illustrate this point, let us take the example of
> a servlet
> delivering content to numerous clients. The servlet
> can build the NDC
> at the very beginning of the request before
> executing other code. The
> contextual information can be the client's host name
> and other
> information inherent to the request, typically
> information contained
> in cookies. Hence, even if the servlet is serving
> multiple clients
> simultaneously, the logs initiated by the same code,
> i.e. belonging to
> the same category, can still be distinguished
> because each client
> request will have a different NDC stack. Contrast
> this with the
> complexity of passing a freshly instantiated
> category to all code
> exercised during the client's request.
>
> Nevertheless, some sophisticated applications, such
> as virtual hosting
> web servers, must log differently depending on the
> virtual host
> context and also depending on the software component
> issuing the
> request. Recent log4j releases support multiple
> hierarchy trees. This
> enhancement allows each virtual host to possess its
> own copy of the
> category hierarchy.
>
> >Of course, that's not to say that you can't use
> your
> >fancy Mapped Diagnostic Context (um, what is it?)
> in
> >the Logging component, as long as it can be
> configured
> >externally (i.e through the log4j.properties file
> in
> >the case of Log4J). Remember, classes like
> Category
> >only matter to the developers not the end users,
> who
> >only have access to the external properties.
> >Therefore, all we need is an API that meets the
> needs
> >of the developer.
>
>
> That is actually my whole point. The NDC (or MDC)
> are programmed. They
> cannot be controlled by config files.
>
> Cheers,
>
> --
> Ceki Gülcü - http://qos.ch
>
Ah I see. Yes, it's unrealistic to provide that kind
of functionality in the Logging component, because it
won't translate well to all logging implementations.
So, it comes down to whether or not a logging
abstraction that doesn't support those kinds of
features still has sufficient value in other cases.
I'm glad that more issues are surfacing in this
discussion. I think that, at the least, we're not so
sure of our opinions as we once were. I'm eager to
see which side prevails. I'll be satisfied with any
outcome other than "punt".
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
