On Fri, Jan 29, 2010 at 1:53 PM, Jeppe Nejsum Madsen <je...@ingolfs.dk>wrote:
> David Pollak <feeder.of.the.be...@gmail.com> writes:
>
> > On Fri, Jan 29, 2010 at 2:40 AM, Jeppe Nejsum Madsen <je...@ingolfs.dk
> >wrote:
> >
> >> Indrajit Raychaudhuri <indraj...@gmail.com> 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 :-)
>
I agree. Clearly a man of superior taste and programming skillz. ;-)
>
> > 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.
>
If you're 100% sure that nothing will break, go for the slf4j-based
approach.
Thanks,
David
>
> /Jeppe
>
> --
> You received this message because you are subscribed to the Google Groups
> "Lift" group.
> To post to this group, send email to lift...@googlegroups.com.
> To unsubscribe from this group, send email to
> liftweb+unsubscr...@googlegroups.com<liftweb%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics
--
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
