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.
Slf4j supports MDC (org.slf4j.MDC) and automatically delegates MDC
functionality to the underlying logging framework if it has support for
such. It's a facade after all.
That said, I think there is room (and opportunity) for defaulting to
lightweight wrapper over slf4j and letting users choose any underlying
framework (simple, log4j, logback, jul) at build/deploy time. I am
optimistic this would be doable without any code change on existing Lift
applications. And keep OSGi happiness in the way.
As such, I thing we should be careful and avoid duplicating (very
similar impl of) MDC enhancement to both Log4JLogger and Slf4JLogger.
I would be inclined to consider:
- Zero code change in application for switching log implementations
(nothing should be necessary to be put in Boot.scala)
- Tuck in everything behind the helper object(s) - Log for the root
logger or other objects introduced because of the Loggable trait
- Have MDC and other enhancements aligned to slf4j. Per design slf4j-api
expects a real logging framework behind it (bundled or otherwise).
- In Lift, for guaranteed compatibility, default to log4j (by using
log4j wrapper of slf4j) - but still allow using logback, jul etc. just
by flipping the dependency during build. Bonus, slf4j would fallback to
simple logger if none of the dependencies are available.
- Existing applications can just add log4j bridge for the existing behavior.
- New applications (generated from archetype) mark slf4j-api as compile
scope dependency and have one of the implementations
(simple,log4j,logback etc.) added as either compile scope or provided
scope (to cover for log4j in container classpath). This can even be
offered as choice during archetype:generate!
Thoughts?
Cheers, Indrajit
On 29/01/10 4:04 AM, David Pollak wrote:
On Thu, Jan 28, 2010 at 2:11 PM, Jeppe Nejsum Madsen <[email protected]
<mailto:[email protected]>> wrote:
Last logging question, I promise!
I'm about to implement MDC in Lift's logging, but it seems more and more
layers are introduced.
So before adding another adapter on top of e.g. Slf4j which is already
an adapter on top of e.g. logback I thought I would see if there are any
objections to making Lift always log through Slf4j?
Yes. I object. There is a way to log through slf4j right now. It's a
one-line addition to boot.scala. I have a very strong preference for
not changing any APIs or defaults. If you want to add or enhance the
mechanics, cool.
There wouldn't be any API changes and Log4j could still be the default
backend, with the config settings as we currently have, only there
wouldn't be any Log4JLogger.
On the positive side, Lift's logging is simpler: only interface to Slf4j
(we would keep the log4j config stuff)
Downside is two more jars if you're using log4j: slf4j-api &
slf4j-log4j12
Thoughts?
/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]
<mailto:[email protected]>.
To unsubscribe from this group, send email to
[email protected]
<mailto:liftweb%[email protected]>.
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 [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.
--
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.
