Upstart Defaults Not Working for Play 2.3.8 Under SBT Native Packager 1.0.0

[CharlesLovely]

QUICK SUMMARY
I am currently working with a Java Play 2.3.8 Web Application, building my distribution as a Debian package using upstart, under Native Packager 1.0.0. Customizing the java server environment doesn't seem to work for Upstart, whether the overrides are specified in project_root/src/universal/conf/application.ini or project_root/src/templates/etc-default.

FULL DETAILS

Under Play 2.3.8, the default version of SBT Native Packager is 0.7.4, which seems to have a bug around permissions for the /var/run/{{app_name}} directory. In looking at the existing closed issues, I am under the impression that these issues have been resolved in later releases of Native Packager, so I'm attempting to upgrade my project to use the latest 1.0.0 release instead.

I've made the following changes in my project to use the latest Native Packager:

project_root/build.sbt

// Removed these lines:
// import com.typesafe.sbt.SbtNativePackager._
// import NativePackagerKeys._
// packageArchetype.java_server

// Modified this line to add DebianPlugin
lazy val root = (project in file(".")).enablePlugins(PlayJava, DebianPlugin)

// Added these lines for good measure, but I'm under the impression that this isn't necessary
import com.typesafe.sbt.packager.archetypes.ServerLoader.{SystemV, Upstart}
serverLoading in Debian := Upstart

project_root/project/plugins.sbt

// Added this line
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.0.0")

Now here's the part where I'm having problems. I want to set a few custom settings:

• save pid to /var/run/{{app_name}}/play.pid
• specify a native library location for a dependency to OpenCV: /usr/share/OpenCV/java/
• specify logging file as /opt/{{app_name}}/logger.xml
• set a variety of environment variables specific to the environment that the app runs in (Dev vs QA vs Prod)

Previously I was able to do all this by putting a /etc/default/{{app_name}} file on the server after installing the built debian package, and it would pick up all the run config specified in that file. Now it seems that doesn't work.

The Native Packager documentation seems to imply that I can simply define a file at project_root/src/universal/conf/application.ini, and that the debian package will be built with configuration specified in that file. But in testing, I found that wasn't the case. For example, having:

project_root/src/universal/conf/application.ini

-Dpidfile.path=/var/run/${{app_name}}/play.pid

Would still result in the upstart service for my app running with a pid defined in /usr/share/{{app_name}}/RUNNING_PID
(still with permission issues, but that's separate issue)

The documentation also suggests that it is still possible to create a etc/default file by defining one at project_root/src/templates/etc-default, and that it would be picked up during building. But it says it only works with SystemV, not Upstart. Regardless, I've tried building with Upstart or SystemV, and anything I put in that file also doesn't seem to be picked up.

I'm trying to determine the exact cause of the problem. Is SBT Native Packager v1.0 simply incompatible with Play v2.3.8? Or is there a mistake in the documentation somewhere?

Appreciate the help! :)

[muuki88]

Thanks for the detailed report. This is an issue with plays configuration file handling. Can you cross post this on the playframework issue tracker?

@Kyprus had similar issue (even with 2.4.0-M3). https://github.com/Kyprus/sbt-native-packager-test

The issue seems to be

• everything in src/universal/conf seems to be filtered by play
• etc-default will get sourced by the systemloader. I'm not sure if you have to configure upstart somehow or source it manually in the upstart exec section

cc @jroper @huntc

[zlangbert]

The issue I filed is here: playframework/playframework#4242

Play uses dist/ as the packager source directory. So dist/conf/application.ini will be put in the right place. What I'm finding out now though is that the file doesn't seem to be proccessed. i.e. {{app_name}} is never replaced. I'm not sure why that is...

[muuki88]

The mappings aren't touched during the build. Only special script files get processed with the linuxScriptReplacements. So

1. There's no need to override bashScriptConfigLocation if you stick to the naming convention
2. If you can process your config file with a custom task

For point 2. it makes sense to integrate this into native packager.