David Pollak <[email protected]> writes: > On Thu, Jan 28, 2010 at 2:11 PM, Jeppe Nejsum Madsen <[email protected]>wrote:
[...] >> 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. Ok > 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. Not sure if you read the next paragraph or not, but there wouldn't be any API or defaults changes. Just two extra jars. Slf4j is already a wrapper on top of the most used backends (log4j, JDK, logback etc). LiftLogger would then just be a more Scala'esque (with by-name params) wrapper on top of Slf4j. Log4j would still be default. But never mind, no big deal. While there's great value in having the LifLogger wrap a logging library, I don't see the same benefits when doing MDC. So I'll not add wrappers for these. >> 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 /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.
