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