David Pollak <[email protected]> writes: > On Fri, Jan 29, 2010 at 2:40 AM, Jeppe Nejsum Madsen <[email protected]>wrote: > >> Indrajit Raychaudhuri <[email protected]> writes: >> >> > I am not sure you need to add yet another adapter on top of slf4j for >> > MDC support. Enhancing the existing slf4j wrapper for the purpsoe >> > might be worth an attempt instead. >> >> Yes but if we introduce a Lift MDC it would need to delegate to either >> Log4j or Slf4j (which already has MDC wrapped for logback & log4j) >> > > Looking at the way the Java frameworks do MDC, I'm not keen on it. > > I'd much rather see some kind of doWith mechanism: > > Log.doWith("name" -> "value", "otherName" -> "otherValue") { > .... > }
Exactly. I was about to implement something along these lines. But if we would still support "native" log4j as well as slf4j, it would mean that I'd have to implement two different MDC implementations (ala Log4jLogger and Slf4jLogger). And this is exactly the problem Slf4j solves, hence the original mail :-) [...] > I'd like to apply Scala and Lift constructs to Logging rather than just > borrow existing paradigms. I agree on the interface part. I think there's good value in leveraging existing logging frameworks for the actual logging as long as there's not too big of an impedance mismatch. > In terms of slf4j, I have a generic allergic reaction to it. Fair enough :-) It is also non-trivial to get these things right in all scenarios with different containers etc (Seems like Slf4j has succeeded where commons-logging has failed though. Just look at the commons-logging classloader problems). > There was a thread 2 years ago on Slf4j that seemed to me to be a > bunch of zealots demanding it as the default without giving any > reasons other than "it's better" (think emacs vs vi.) But clearly emacs is better :-) > If there are real reasons to insert it into the mix, I'll listen to > them, but I'd rather start at a design that's Scala and Lift-like and > move down the implementation stack to see why it's a win to insert > slf4j. The real benefit, as I see it, is that the Lift code can concentrate on providing a Scala/Lift interface to logging, programmed against a single well defined (imho) API while still giving the user full flexibility on the actual logging backend (log4j, JDK, logback etc) But we've already spent quite some time back and forth on this (minor) issue, so I'll just implement MDC in the same way as the current loggers. If we keep a sane interface, we can always change the implementation later if deemed necessary. /Jeppe -- You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
