[slf4j-dev] Transactions in slf4j?

[Ralph Goers]

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