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
