You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Sean C. Sullivan" <se...@seansullivan.com> on 2002/10/10 03:02:59 UTC
[logging] Log4j's NDC and MDC
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
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Log4j's NDC and MDC
Posted by Ceki Gülcü <ce...@qos.ch>.
At 13:40 10.10.2002 -0700, you wrote:
>Ceki Gülcü wrote:
>
> > 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.
>
>There is a tiny problem here - if per thread info is used and a
>servlet forgets to pop(), all other servelets in the
>same thread will be screwed.
Wrong information will appear, yes.
>That makes abstracting this feature very important - to allow the
>container to cleanup the context after each servlet ( there are
>other things that the container need to be able to do for separation ).
???
> >>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.
>
>Well, I'm not sure what's the exact behavior - but creating a NDC stack per
>thread and adding the context before calling jdk1.4 logging doesn't
>seem to complicated. I'm sure the native implementation is better, but
>the workaround seems plausible.
You can easily reproduce the MDC or NDC code, that is not the issue. Having
JDK 1.4 logging to *use* the contextual information is the show stopper.
>Ceki - any proposal for the API ?
Not at this stage.
>What about a new interface with the method you mentioned ( we can't use
>static - since we need to support multiple implementations ) ? Then
>add a method to get the implementation for each supported logger
>( that would be in LogFactory ).
You could indeed get the appropriate "MDC" implementation from some
factory. However, if you consider that the classloader in use may vary for
the same thread, things start to get complicated.
>--
>Costin
--
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Log4j's NDC and MDC
Posted by Costin Manolache <cm...@yahoo.com>.
Ceki Gülcü wrote:
> 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.
There is a tiny problem here - if per thread info is used and a
servlet forgets to pop(), all other servelets in the
same thread will be screwed.
That makes abstracting this feature very important - to allow the
container to cleanup the context after each servlet ( there are
other things that the container need to be able to do for separation ).
>>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.
Well, I'm not sure what's the exact behavior - but creating a NDC stack per
thread and adding the context before calling jdk1.4 logging doesn't
seem to complicated. I'm sure the native implementation is better, but
the workaround seems plausible.
Ceki - any proposal for the API ?
What about a new interface with the method you mentioned ( we can't use
static - since we need to support multiple implementations ) ? Then
add a method to get the implementation for each supported logger
( that would be in LogFactory ).
--
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Log4j's NDC and MDC
Posted by Ceki Gülcü <ce...@qos.ch>.
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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Log4j's NDC and MDC
Posted by Costin Manolache <cm...@yahoo.com>.
I haven't used this feature - if anyone can provide a short
description and a proposal for API it'll probably have my
+1.
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.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Log4j's NDC and MDC
Posted by Ceki Gülcü <ce...@qos.ch>.
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
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [logging] Log4j's NDC and MDC
Posted by Steve Downey <st...@netfolio.com>.
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?
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
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>