Use Logback instead of log4j about dropwizard HOT 13 CLOSED

@christophercurrie For libraries, certainly, but Dropwizard is an opinionated, batteries-included framework. Punting on a logging backend would be yet another bit of glue code everyone has to write themselves, and the whole point of Dropwizard is to keep people from having to write glue code.

from dropwizard.

At the end of the day I don't feel that strongly about it, so long as it's possible to use the backend that makes sense for the project at hand. That said:

@codahale: Configuring a slf4j backend requires no code. You put the appropriate backend jar in your classpath or Maven dependencies and you're done. The impact to the end user would be to require the addition of the 'slf4j-log4j12' jar (if they wanted to stick with the currently default log4j) to the pom. If you want to continue to provide that by default, I suppose it's always possible for me to add a dependency exclusion, but I personally find that irritating to have to do. YMMV.

@klauern: I find that I end up tweaking with logging on a per-project basis anyway, just to configure it for the messages my application is emitting. I have a standard logging configuration file that I start from, and tweak accordingly, just because the default is almost never what I want. Maybe I'm more picky about my logging than most users, so my uses cases aren't appropriate here. But yes, I'm saying that logging backend should be an explicit choice (and usually is, because folks can have strong feelings about it).

Where I've been burnt in the past is that Jetty has, over various versions, had burnt-in backends that have to be specially configured to be turned off, and it's typically been a pain to get right.

from dropwizard.

@christophercurrie Most programmers do, since just about all of us have been painted into a corner by a pig-headed library before. ;) Believe me, I wish the Jersey folks had gone with slf4j instead of j.u.l (really — who does that?).

I'm always open to hearing about unmet needs with Dropwizard, but something like logging is one of those batteries that needs to be included.

from dropwizard.

Is there a log4j to logback bridge?

I wouldn't mind using something under active development, but a lot of libraries depend directly on log4j.

Logback users tend to write libraries with slf4j dependencies, which ironically makes it easier to use log4j.

from dropwizard.

Hmm. Looks like there's a bridge for log4j. I'll look into it.

from dropwizard.

From personal experience I think the nicest approach is to only expose a dependency on slf4j-api. If the end user doesn't configure a backend it spits out a warning to stderr and then shuts up. Then users can make their own choice, logback, commons-logging, log4j, whatever.

from dropwizard.

@christophercurrie I would think that's an extreme position to take. Are you suggesting to make the user configure their logging framework of choice every time they want to create a new project?

Right now, it's log4j, which I can settle with, but if there was something exposed that I could switch it out if I wanted to, I would be able to do that at my discretion and not impact anybody else's use of the tool.

from dropwizard.

@christophercurrie I know, I've been using slf4j for years. Configuring the backend that you end up choosing, however, is the glue code that Dropwizard serves to obviate by implementing it once and only once. Dropwizard will never support more than one backend.

from dropwizard.

@christophercurrie If there's a use case which Dropwizard's logging support doesn't handle, I'd be very interested to hear it. But Dropwizard, as a project, exists exclusively to reduce the transactional cost of introducing a new service into a production environment.

I'd much rather figure out how to write a logging infrastructure which actually meets people's needs rather than just punting entirely and adding the cost of selecting and configuring a logging framework to the transactional costs of new services (and the divergence as teams select and configure differently to the operational costs of those services).

from dropwizard.

That's fair, and I admit I have not yet taken the time to play
extensively with DropWizard to identify any specific weakness in this
area. I'm supportive of the original request of logback as a default,
as that's my preferred backend; I was simply interested in keeping
things flexible.

On Thu, Mar 15, 2012 at 9:36 AM, Coda Hale
[email protected]
wrote:

@christophercurrie If there's a use case which Dropwizard's logging support doesn't handle, I'd be very interested to hear it. But Dropwizard, as a project, exists exclusively to reduce the transactional cost of introducing a new service into a production environment.

I'd much rather figure out how to write a logging infrastructure which actually meets people's needs rather than just punting entirely and adding the cost of selecting and configuring a logging framework to the transactional costs of new services (and the divergence as teams select and configure differently to the operational costs of those services).

---

Reply to this email directly or view it on GitHub:
https://github.com/codahale/dropwizard/issues/52#issuecomment-4523438

@('_')@
Christopher Currie [email protected]

from dropwizard.

Pretty much done at this point!

from dropwizard.

I have been out of state for the better part of a month, so I just got to this. I just wanted to say 'Thank You' for your work in this ticket. It's appreciated.

from dropwizard.

@christophercurrie Curious about how you're dealing with the logger. The current version is hard coded to use logback, if I want to use log4j in my system, how should I do it? Thanks!

from dropwizard.