Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

[2.1] Logging levels configuration in application.conf is ignored in production mode (dist) #1186

Merged
merged 1 commit into from Aug 7, 2014

Conversation

Projects
None yet

jroper commented Aug 7, 2014

The following login configuration in application.conf works in DEV mode but not in a DIST. release:

logger.root=DEBUG
logger.play=DEBUG
logger.application=DEBUG

These loggin levers are loaded into logback in the Application.scala class

   Logger.configure(
      Map("application.home" -> path.getAbsolutePath),
      configuration.getConfig("logger").map { loggerConfig =>
        loggerConfig.keys.map {
          case "resource" | "file" | "url" => "" -> null
          case key @ "root" => "ROOT" -> loggerConfig.getString(key, Some(validValues)).map(setLevel).get
          case key => key -> loggerConfig.getString(key, Some(validValues)).map(setLevel).get
        }.toMap
      }.getOrElse(Map.empty),
      mode)

However this configuration gets replaced by this other code in the Server trait when running in DIST. mode:

  // Configure the logger for the first time
  Logger.configure(
    Map("application.home" -> applicationProvider.path.getAbsolutePath),
    mode = mode)

The logger is reset and all config is lost.

As I understand it, the Server trait constructor should be loaded before Application.scala, but it seems it is the other way around.

galderz commented Jun 7, 2013

I had that issue when integrating Play on top of Escalante. Play was clearing all base logging set up. I did workaround it by caching the settings, starting the application, and the resetting them again. Hacky but kinda works. I'd love to see more sane logging in Play...

monzonj commented Jun 7, 2013

Hey @galderz I've been trying to also reset the log levels by calling again the Logger.configure(...) after the startup. But I cannot figure where to do this. Even overriding the play.api.GlobalSettings.onStart method it won't take it.

Where do you do the resetting?

((I just find very annoying having to keep yet another config file -logback.xml- for DIST. releases, application.conf should be enough))

galderz commented Jun 7, 2013

I do the resetting here. Basically, take all logging handlers, cache them and then reapply them here, once the application has started.

I dunno how you'd do the same on an end-user application though. You can deploy Play apps on top Escalante and hence we did some work to control their lifecycle, which gives us the chance to do things like this.

Collaborator

nraychaudhuri commented Jun 7, 2013

The reset in production mode happens because play ships with it logger.xml file https://github.com/playframework/Play20/blob/master/framework/src/play/src/main/resources/logger.xml

I need to investigate why play is shipping its own logger.xml file maybe we can get ride of it. One workaround would be to specify your own application-logger.xml file in prod mode.

Contributor

mslinn commented Jun 11, 2013

I have been bitten by this issue as well. I am presently providing a custom logger configuration via

export JAVA_OPTS="-Dlogger.file=conf/application-logger.xml"

...but this is suboptimal.

I'm suffering through this as well. The net result of this bug seems to be that all mention of logger settings has been removed from the 2.1.x and 2.2.x documentation.

Is the only way to get logging levels different from the default in production to provide a command-line argument with a path to a custom application-logger.xml file?

Very annoying issue, by the way using -Dlogger.file doesn't works with 2.1.3, so there is totally no way to have log configuration in prod mode without hacking source code

Contributor

seantbrady commented Aug 23, 2013

Putting application-logger.xml in your /conf directory should work without a command line argument.

@seantbrady yes it will work, but just one second, after, the logger is reset and all config is lost, that's where is the problem.

Contributor

damianball commented Sep 21, 2013

@serphacker, I'm using Play 2.1.4 and I've added an application-logger.xml file into my conf directory. After setting the application log level to INFO and deploying to production... my configuration changes seems to be stable.

Still... the documentation requires some updating. I was confused for about 30 minutes before I found this issue page and this one on google groups (https://groups.google.com/forum/#!topic/play-framework/cAvr2vRtyI0).

Thanks!

Collaborator

huntc commented Sep 24, 2013

Is there anyone that can quickly confirm whether this is a 2.2.x issue also? If so then we may deal with this the same way we dealt with overriding ehcache configuration i.e. we provide a default configuration given an irregular name thus if the user provides a regular name then it succeeds in terms of priority.

If it is a 2.1.x issue then we may be able to do something here, but given that 2.2.x is out, probably only as a customer support request.

ericMK commented Oct 28, 2013

I'm also seeing this issue in 2.2.0-RC2. mslinn's -Dlogger.file=conf/application-logger.xml flag workaround is getting me by, thanks Mike! Please do fix as I spent a day trying things, reseaching, etc. and we all want to see Play succeed, not frustrating users.

@ghost

ghost commented Mar 10, 2014

Confirmed that the workaround works! I really appreciate it.

monzonj commented Mar 14, 2014

Yes, still happening in 2.2.

You can do that hack with the filenames, but really, I don't get what the big deal is. The trait Server.scala has a bug that prevents the proper Logger initialization. Why not fixing that?

Replace:

  // Configure the logger for the first time
  Logger.configure(
    Map("application.home" -> applicationProvider.path.getAbsolutePath),
    mode = mode)

With:

   Logger.configure(
      Map("application.home" -> path.getAbsolutePath),
      configuration.getConfig("logger").map { loggerConfig =>
        loggerConfig.keys.map {
          case "resource" | "file" | "url" => "" -> null
          case key @ "root" => "ROOT" -> loggerConfig.getString(key, Some(validValues)).map(setLevel).get
          case key => key -> loggerConfig.getString(key, Some(validValues)).map(setLevel).get
        }.toMap
      }.getOrElse(Map.empty),
      mode)

((You might want to do some re-factoring because the code above also exists in Application.scala, which is correctly setting up the logger))

Contributor

nremond commented Apr 26, 2014

@huntc will something be done?

Collaborator

huntc commented Apr 30, 2014

@nremond Would you like to try and tackle the issue via a PR? :-)

Contributor

makoConstruct commented May 8, 2014

I don't know if this is the same issue, but I'm finding that standalone dists actually ignore the configuration file conf/application.conf in favour of another application.conf that's bundled inside the lib/.--SNAPSHOT.jar file.

Ensure appplication.conf log configuration works in prod
Fixes #1186.

The logger is configured in the constructor of Application.  However, it
was also being configured in the constructor of Server, this was so that
in dev mode, when the server first started up, before any application
existed, the default (or overridden default) configuration is applied.
The problem was, this was overriding the config done in Application,
since in prod mode, the server is instantiated after the application.

So, I moved the dev mode logging configuration concerns into
ReloadableApplication, which is instantiated during the instantiation of
the server in dev mode, and so effectively happens at the same time as
it used to.
Owner

jroper commented Aug 7, 2014

Pull request attached, commit message repeated here:

The logger is configured in the constructor of Application. However, it was also being configured in the constructor of Server, this was so that in dev mode, when the server first started up, before any application existed, the default (or overridden default) configuration is applied. The problem was, this was overriding the config done in Application, since in prod mode, the server is instantiated after the application.

So, I moved the dev mode logging configuration concerns into ReloadableApplication, which is instantiated during the instantiation of the server in dev mode, and so effectively happens at the same time as it used to.

Backport to 2.3.x required.

@jroper jroper added this to the 2.3.3 milestone Aug 7, 2014

@jroper jroper self-assigned this Aug 7, 2014

pvlugter added a commit that referenced this pull request Aug 7, 2014

Merge pull request #1186 from jroper/1186-prod-logging
[2.1] Logging levels configuration in application.conf is ignored in production mode (dist)

@pvlugter pvlugter merged commit d5f3bfd into playframework:master Aug 7, 2014

1 check passed

default Merged build finished.
Details

jroper added a commit that referenced this pull request Aug 7, 2014

Ensure appplication.conf log configuration works in prod
Fixes #1186.

The logger is configured in the constructor of Application.  However, it
was also being configured in the constructor of Server, this was so that
in dev mode, when the server first started up, before any application
existed, the default (or overridden default) configuration is applied.
The problem was, this was overriding the config done in Application,
since in prod mode, the server is instantiated after the application.

So, I moved the dev mode logging configuration concerns into
ReloadableApplication, which is instantiated during the instantiation of
the server in dev mode, and so effectively happens at the same time as
it used to.
Collaborator

pvlugter commented Aug 7, 2014

2.3.x backport: f112290

@jroper jroper deleted the jroper:1186-prod-logging branch Aug 8, 2014

@jroper jroper referenced this pull request Aug 8, 2014

Closed

Sort out logging in tests #1717

cdraeger pushed a commit to cdraeger/playframework that referenced this pull request Sep 29, 2014

Ensure appplication.conf log configuration works in prod
Fixes #1186.

The logger is configured in the constructor of Application.  However, it
was also being configured in the constructor of Server, this was so that
in dev mode, when the server first started up, before any application
existed, the default (or overridden default) configuration is applied.
The problem was, this was overriding the config done in Application,
since in prod mode, the server is instantiated after the application.

So, I moved the dev mode logging configuration concerns into
ReloadableApplication, which is instantiated during the instantiation of
the server in dev mode, and so effectively happens at the same time as
it used to.

@SRGOM SRGOM referenced this pull request Dec 5, 2014

Closed

production logging #3713

jolleon commented Aug 24, 2015

We just upgraded from play 2.2.3 to 2.3.9 and seeing the same issue. We have our logging configs in a logger.xml file for dev and syslog-logger.xml for prod, but prod seems to ignore the log levels we set.

This setup was working fine before we upgraded (i.e. with play 2.2.3).

Can someone confirm whether this is still an issue in play 2.3.9 or if we missed something else?

ClaraAllende pushed a commit to ClaraAllende/playframework that referenced this pull request Aug 28, 2015

Ensure appplication.conf log configuration works in prod
Fixes #1186.

The logger is configured in the constructor of Application.  However, it
was also being configured in the constructor of Server, this was so that
in dev mode, when the server first started up, before any application
existed, the default (or overridden default) configuration is applied.
The problem was, this was overriding the config done in Application,
since in prod mode, the server is instantiated after the application.

So, I moved the dev mode logging configuration concerns into
ReloadableApplication, which is instantiated during the instantiation of
the server in dev mode, and so effectively happens at the same time as
it used to.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment