|
Log4j 1.3alpha-8 | |||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object | +--org.apache.log4j.NDC
The NDC class implements nested diagnostic contexts as defined by Neil Harrison in the article "Patterns for Logging Diagnostic Messages" part of the book "Pattern Languages of Program Design 3" edited by Martin et al.
A Nested Diagnostic Context, or NDC in short, is an instrument to distinguish interleaved log output from different sources. Log output is typically interleaved when a server handles multiple clients near-simultaneously.
Interleaved log output can still be meaningful if each log entry from different contexts had a distinctive stamp. This is where NDCs come into play.
Note that NDCs are managed on a per thread
basis. NDC operations such as push
, pop()
, clear()
, getDepth()
and setMaxDepth(int)
affect the NDC of the current thread only. NDCs of other
threads remain unaffected.
For example, a servlet can build a per client request NDC
consisting the clients host name and other information contained in
the the request. Cookies are another source of distinctive
information. To build an NDC one uses the push
operation. Simply put,
NDC.push
. As a
side effect, if there is no nested diagnostic context for the
current thread, this method will create it.
NDC.pop
.
NDC.remove()
when exiting a thread..
There is no penalty for forgetting to match each
push
operation with a corresponding pop
,
except the obvious mismatch between the real application context
and the context set in the NDC.
If configured to do so, PatternLayout
and TTCCLayout
instances automatically retrieve the nested diagnostic
context for the current thread without any user intervention.
Hence, even if a servlet is serving multiple clients
simultaneously, the logs emanating from the same code (belonging to
the same category) can still be distinguished because each client
request will have a different NDC tag.
A thread may inherit the nested diagnostic context of another
(possibly parent) thread using the inherit
method. A thread may obtain a copy of its NDC with the cloneStack
method and pass the reference to any other
thread, in particular to a child.
Method Summary | |
static void |
clear()
Clear any nested diagnostic information if any. |
static Stack |
cloneStack()
Clone the diagnostic context for the current thread. |
static String |
get()
Never use this method directly, use the LoggingEvent.getNDC() method instead. |
static int |
getDepth()
Get the current nesting depth of this diagnostic context. |
static void |
inherit(Stack stack)
Inherit the diagnostic context of another thread. |
static String |
peek()
Looks at the last diagnostic context at the top of this NDC without removing it. |
static String |
pop()
Clients should call this method before leaving a diagnostic context. |
static void |
push(String message)
Push new diagnostic context information for the current thread. |
static void |
remove()
Remove the diagnostic context for this thread. |
static void |
setMaxDepth(int maxDepth)
Set maximum depth of this diagnostic context. |
Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Method Detail |
public static void clear()
This method is equivalent to calling the setMaxDepth(int)
method with a zero maxDepth
argument.
public static Stack cloneStack()
Internally a diagnostic context is represented as a stack. A given thread can supply the stack (i.e. diagnostic context) to a child thread so that the child can inherit the parent thread's diagnostic context.
The child thread uses the inherit
method to
inherit the parent's diagnostic context.
public static void inherit(Stack stack)
The parent thread can obtain a reference to its diagnostic
context using the cloneStack()
method. It should
communicate this information to its child so that it may inherit
the parent's diagnostic context.
The parent's diagnostic context is cloned before being inherited. In other words, once inherited, the two diagnostic contexts can be managed independently.
In java, a child thread cannot obtain a reference to its parent, unless it is directly handed the reference. Consequently, there is no client-transparent way of inheriting diagnostic contexts. Do you know any solution to this problem?
stack
- The diagnostic context of the parent thread.public static String get()
LoggingEvent.getNDC()
method instead.public static int getDepth()
setMaxDepth(int)
public static String pop()
The returned value is the value that was pushed last. If no context is available, then the empty string "" is returned.
public static String peek()
The returned value is the value that was pushed last. If no context is available, then the empty string "" is returned.
public static void push(String message)
The contents of the message
parameter is
determined solely by the client.
message
- The new diagnostic context information.public static void remove()
As of log4j 1.3, the NDC
class uses ThreadLocal
technology to store the context. It is no longer necessary to call this
method. It remains for backwards compatibility.
public static void setMaxDepth(int maxDepth)
maxDepth
, then no
action is taken.
This method is a convenient alternative to multiple pop()
calls. Moreover, it is often the case that at the end of
complex call sequences, the depth of the NDC is
unpredictable. The setMaxDepth
method circumvents
this problem.
For example, the combination
void foo() { int depth = NDC.getDepth(); ... complex sequence of calls NDC.setMaxDepth(depth); }ensures that between the entry and exit of foo the depth of the diagnostic stack is conserved.
getDepth()
|
Log4j 1.3alpha-8 | |||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |