commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: [logging] Log4j's NDC and MDC
Date Thu, 10 Oct 2002 20:06:23 GMT
At 12:28 10.10.2002 -0700, you wrote:
>I haven't used this feature - if anyone can provide a short
>description and a proposal for API it'll probably have my
>+1.

 From the log4j Manual:

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 logger for
each client. This promotes the proliferation of loggers 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 logger 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 logger, can still be distinguished because each client
request will have a different NDC stack. Contrast this with the
complexity of passing a freshly instantiated logger to all code
exercised during the client's request.

MDCs are similar except that they are map based instead of a stack.

>Regarding no-op - it may be better to try to provide a 'default'
>or baseline implementation, if possible ( even if the behavior will
>be inefficient ). At least IMO, commons-logging should provide
>a common API but also try to harmonize the behavior.

You can't really do that because the MDC has to be handled internally by 
the implementation.

>Costin
>
>Ceki Gülcü wrote:
>
> > At 11:10 10.10.2002 -0400, Steve Downey wrote:
> >>It looks like the concept is available in both LogKit and Log4J, although
> >>in slightly differenct forms. I don't know if the forms are compatible.
> >>
> >>It's not available in JDK 1.4 logging.
> >>
> >>So, the question is two-fold. Can the differences between LogKit and Log4J
> >>be harmonized, and is this useful if it might be a no-op?
> >
> > Yes on both accounts. Yes they should be compatible, and yes a no-op under
> > JDK 1.4 is better than having nothing under log4j or logkit.
> >
> >
> >>On Wednesday 09 October 2002 09:02 pm, Sean C. Sullivan wrote:
> >> > I spotted this message on the jboss-developer mailing list.
> >> >
> >> > > -----Original Message-----
> >> > > From: Jason Dillon [mailto:jason@pl...]
> >> > > Sent: Tuesday, October 08, 2002 8:24 PM
> >> > > To: jboss-development@li...
> >> > > Subject: RE: [JBoss-dev] Design: Plans to decouple JBoss from log4j
> >> > >
> >> > >
> >> > > It is too bad commons logging does not provide abstractions
> >> > > for a ContextStack or ContextMap similar to Log4j's NDC and
> >> > > MDC.  These are valuable constructs.
> >> > >
> >> > > Do you know anyone on the commons logging team?
> >> > >
> >> > > --jason
> >
> > --
> > Ceki
> >
> > TCP implementations will follow a general principle of robustness: be
> > conservative in what you do, be liberal in what you accept from
> > others. -- Jon Postel, RFC 793
>
>--
>Costin
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>

--
Ceki

TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793



--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message