Stop Play from butchering logback settings #7

astubbs opened this Issue Apr 10, 2012 · 12 comments


None yet

5 participants

astubbs commented Apr 10, 2012

Once turning on play2mini:

NettyServer.createServer(new File(System.getProperty("user.dir")));\

, play2 butchers existing logback setups, overwriting them with the logback config here:

[jar:file:/Users/TStubbs/.gradle/caches/artifacts-8/filestore/play/play_2.9.1/2.0/jar/7ef90148d97ccffb1eb7ec692fc8fe6d618c6c80/play_2.9.1-2.0.jar!/logger.xml] is not of type file

After I start the container, running the lines:

    Logger root = (Logger)LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME);

confirms it, as i can then see my log statements again, but the formatting and everything else is still overridden with Play's settings.

astubbs commented Apr 12, 2012

After much frustration, a workaround is that you can tell play what logback.xml config to use. If left off, it will use it's default override.
I.e.: -Dlogger.resource=logback.xml

play.api.Logger#configure, line 236-252:
      Option(System.getProperty("logger.resource")).map(s => if (s.startsWith("/")) s.drop(1) else s).map(r => Option(this.getClass.getClassLoader.getResource(r)).getOrElse(new"file:///" + System.getProperty("logger.resource")))).
        orElse {
        orElse {
        orElse {
          if (mode != Mode.Test) {
          } else {
        map { url =>

But this isn't a fix. I think this will be ironed out when the actual libraries that play2-mini depends on are separated out from the rails like application that is Play. I.e. this functionality doesn't belong in a library.

There was an issue for that separation work, but I can't remember where it was to track it? :/

pk11 commented Apr 15, 2012

please note, the modularization effort won't effect this behavior since logging is and will be in the core jar.

I think the easiest and best way to fix this is to modify the g8 templates. ie adding something like

// if you use logback and want to use your own configuration file as opposed to the play default one
// uncomment this line and set it to the correct location

this to project/Build.scala

astubbs commented May 6, 2012

Does play bind to logback and not slf4j?

astubbs commented Jun 20, 2012

wasargent, what are you actually referring to? Play takes over your logback settings directly, unless you specify the logback config that Play should use. Quite unexpected behavior in a "library" (I say library in reference to using play2-mini as opposed to Play proper).


There are numerous bugs with logging in Play, and it looks like specifying the logback config directly is the best answer to most of them. It doesn't look there's any ideal way to fix it in play2-mini itself.

astubbs commented Jun 21, 2012

IMO Play2mini should be structured in such a way, and transitively Play, that they are use in library like fashions - which means no direct binding to logback.

astubbs commented Jul 23, 2012

pk11: just a little but from the slf4j website, this is one way of looking at logging, and part of why i don't think play2-mini should inherit Play's logging baggage.
from :

Should my library attempt to configure logging?
Embedded components such as libraries not only do not need to configure the underlying logging framework, they really should not do so. They should invoke SLF4J to log but should let the end-user configure the logging environment. When embedded components try to configure logging on their own, they often override the end-user's wishes. At the end of the day, it is the end-user who has to read the logs and process them. She should be the person to decide how she wants her logging configured.


+1 on the last quote from slf4j FAQ. I usually dont like it when they package own logger configs in the library and explicitly load it programmatically during init time.

ijuma commented Aug 22, 2012

Yes, libraries should not configure logging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment