On Jun 2, 2009, at 12:52 AM, Thorbjørn Ravn Andersen wrote:
Ralph Goers skrev den 02-06-2009 01:52:
We have a class called RequestContext. All it contains is a bunch
of constants and static helper methods to store fields into the
MDC. At the start of every request we call
RequestContext.initialize(). That clears the MDC and then adds a
key named "id" that contains a java.util.UUID as a String. The
"RequestContext" is then passed throughout the application and is
even serialized and passed to remote systems so that the
distributed request can be captured and aggregated in logs.
Is this what you are after?
Sounds interesting. Then I would have the actual calls to the API
in here (disconnected from slf4j as such) and write a suitable
appender.
I was basically wondering if this abstraction was essentially
something that would make sense to have in the API too.
You don't really need much. As I said, the only value RequestContext
has over the MDC itself is that it is where all the MDC keys are
defined. Unless we are going to have universal agreement over a
minimum set of keys then there isn't really a good way to do it. The
other portion that is needed, of course, is the piece of code that
sets up the MDC. I created an example of this in the EventLogger
documentation that is in trunk - look at extensions.html in the
section under event logging. I should add one more line in the sample
filter to do MDC.put("requestId", java.util.UUID.randomUUID());.
Unfortunately, this routine can't really be standardized because where
some of the information comes from will be unique to your environment.
As far as the Appender goes, the MDC can already be handled by the
PatternLayout, but if you want other handling then you could create
your own Appender.
Also, the company I work for is an Application Service Provider so the
software we are running runs on behalf of many clients. When we first
populate the MDC we put the clients id into the MDC. Then we use
frameworks, such as Apache Commons Configuration, that can access the
MDC information to determine the client and use it to behave
accordingly. In the case of Commons Configuration, each client can
have their own configuration making the application behave differently
for each one.
The point here is that the value of the MDC goes far beyond just for
use in logging.
Ralph
_______________________________________________
dev mailing list
[email protected]
http://www.slf4j.org/mailman/listinfo/dev
