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) > 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. That was my proposal > As such, I thing we should be careful and avoid duplicating (very > similar impl of) MDC enhancement to both Log4JLogger and Slf4JLogger. I agree and this was what caused me to write the email in the first place :-) > 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) As long as you don't want to tweak the backend config. I think you still need to configure the underlying logging framework in order to support reading (dev|prod|test) config files. > - 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? That was pretty much what I had in mind, but probably didn't articulate too well :-) I'll wait for David to chime in since he had objections. In the meantime, I've pushed the changes (keeping the Log4j logger) to http://github.com/dpp/liftweb/tree/jnm_issue_309 I've updated the hellolift example to use Slf4j over logback. /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.
