Re: org.apache.log4j.MDC vs. org.slf4j.MDC
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 sco...@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-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: org.apache.log4j.MDC vs. org.slf4j.MDC
On 02.11.2011 04:04, Steve Cohen wrote: But why was the ability to store non-Strings [in MDC] removed between log4j and slf4j in the first place? Since java Strings are immutable, once inserted into the MDC, values cannot be changed (voluntarily or otherwise). This makes SLF4J-style MDC more predictable and less error prone. Of course, SLF4J's the stricter MDC interface allows less flexibility. -- Ceki http://twitter.com/#!/ceki - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
org.apache.log4j.MDC vs. org.slf4j.MDC
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-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
