Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Stop Play from butchering logback settings #7

Open
astubbs opened this Issue · 12 comments

5 participants

@astubbs

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.

@astubbs

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? :/

@pk11

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

@astubbs

Does play bind to logback and not slf4j?

@astubbs

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

@wsargent
Owner

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

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

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.

@ijuma

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.