Skip to content
This repository

Stop Play from butchering logback settings #7

Open
astubbs opened this Issue April 09, 2012 · 12 comments

5 participants

Antony Stubbs Peter Hausel Will Sargent smartnut007 Ismael Juma
Antony Stubbs

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);
    root.setLevel(Level.INFO);

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

Antony Stubbs

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 java.net.URL("file:///" + System.getProperty("logger.resource")))).
        orElse {
          Option(System.getProperty("logger.file")).map(new java.io.File(_).toURI.toURL)
        }.
        orElse {
          Option(System.getProperty("logger.url")).map(new java.net.URL(_))
        }.
        orElse {
          if (mode != Mode.Test) {
            Option(this.getClass.getClassLoader.getResource("logger.xml"))
          } else {
            None
          }
        }.
        map { url =>
          configurator.doConfigure(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? :/

Peter Hausel
pk11 commented April 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
//System.setPropert("logger.resource","mylocation/logger.xml")

this to project/Build.scala

Antony Stubbs
astubbs commented May 06, 2012

Does play bind to logback and not slf4j?

Antony Stubbs

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).

Will Sargent

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.

Antony Stubbs

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.

Antony Stubbs

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 : http://www.slf4j.org/faq.html#configure_logging

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.

smartnut007

+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.

Ismael Juma

Yes, libraries should not configure logging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.