commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: [logging] Log4j's NDC and MDC
Date Thu, 10 Oct 2002 20:40:42 GMT
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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message