logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacob Kjome" <h...@visi.com>
Subject Re: org.apache.log4j.MDC vs. org.slf4j.MDC
Date Wed, 02 Nov 2011 15:31:39 GMT

Hi Steve,

Your question really should be directed to the SLF4J mailing list [1], as 
Log4j already provides what you need.  Your question deals with "why doesn't 
SLF4J provide what Log4j provides", which the Log4j team cannot 
authoritatively answer.

[1] http://slf4j.org/mailing-lists.html


Jake

On Tue, 01 Nov 2011 22:04:24 -0500
 Steve Cohen <scohen@javactivity.org> wrote:
> I haven't used MDC's in awhile but today I thought I saw a way to put them 
>to advantage for an application I'm working on.  In doing so, though ,I 
>stumbled upon an incompatibility between log4j's MDC and slf4j's MDC that 
>I've not seen much comment on.
> 
> The signatures for the get() and put() methods in the two MDC classes are 
>incompatible.
> 
> In log4j, it's
> 
> public static Object get(String key)
> 
> and
> 
> public static void put(String key,
>                        Object o)
> while in slf4j (and logback), it's
> 
> public static String get(String key)
>                 throws IllegalArgumentException
> and
> 
> public static void put(String key,
>                        String val)
>                 throws IllegalArgumentException
> 
> I'm not concerned about the exceptions as much as I am about the restriction 
>to Strings.
> 
> It so happens that the use case I came up with today much prefers objects to 
>Strings as things to put on an MDC.  Admittedly, my use case is a bit 
>non-standard.  Basically I want to defer to append-time in the case of one 
>appender the decision as to whether to emit or not emit a log message.  We 
>are interfacing to a legacy system and want to use a JMS Queue Appender to 
>send messages to the server for this legacy system.  This system uses its own 
>system of bitmapped filters to control output and we have to use it.  We'd 
>like to restrict logging to this appender, whereas, possibly not restrict it 
>in the case of other optional local appenders on the client side, by this 
>method.  The way I hit upon to do that was to defer the go/no-go decision to 
>the appender in the case of the JMS Queue appender.  But to do that I need to 
>put non-Strings on the MDC.
> 
> Converting these longs to and from a String seems like a somewhat heavy 
>penalty to pay just to be able to use slf4j instead of log4j which I'd much 
>prefer to do otherwise.  With non-Strings in the MDC, I just OR two longs 
>together at the appender and abort the log.
> 
> I suppose I could just or them together at logging time and store true or 
>false in the MDC which only the JMS appender would look at.  That's probably 
>the best thing to do.  But why was the ability to store non-Strings removed 
>between log4j and slf4j in the first place?
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message