Modifying /etc/app/application.conf not taken in account after restart

[gbougeard]

Hi,

I packaged a Play (2.3.4) app with sbt-native-packager (0.7.4).
When I modify the /etc/myApp/application.conf and then restart the service, the modifications are not taken in account. So, I believe this file is not used.

To "fix" it, I had to add -Dconfig.file=/etc/jmyApp/application.conf to the JAVA_OPTS to the /etc/default/myApp file.
But that means I will have to do the same after the next apt-get upgrade myApp :(

[lpeter91]

Hello,

The reason for this is that the Play framework loads the configs (actual configs and message files etc) from the classpath. The sbt packager does not add the config folder to the classpath in the start script (/usr/share/pkg/bin/pkg) , and there's no way to make it do so (for security reasons, as I've read). Maybe with a custom start script template, but that's really ugly. Easier solution is to edit the start script itself and prefix the classpath with the config folder, but that's also really ugly. Also, in this case your package is not working "out of the box", which isn't great either. I believe this is a bug, or more of an incompatibility between the framework and the tool, which should be addressed on either side.

Your issue can be fixed with an etc-default template (see http://www.scala-sbt.org/sbt-native-packager/GettingStartedServers/AddingConfiguration.html). Just add the line
-Dconfig.file=/etc/${{app_name}}/application.conf
to src/templates/etc-default, and the generated package will do by itself what you just did by hand (ie. apt-get upgrade will work).

BUT there's no such hack for the messages files, so it's still a bug.

[muuki88]

@lpeter91 is correct. The right approach is to generate an etc-default, which is your default configuration. See Stackoverflow and Examples.

Despite security, classpath ordering is an even bigger problem here. If you have two application.conf files, the first one found, will be used. This generates often some confusion, especially, when you have other resources in your conf folder.

Looking at the playframework i18n code, it seems that it's not build for using external files. I would rather recommend opening a feature request there.

However you can always extend scriptClasspath, which I would not recommend, unless you have no other options

scriptClasspath := {
   val path = scriptClasspath.value
   "/etc/yourapp/*" +: scriptClasspath
}