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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
