How to specify JAVA_OPTS for JavaServer archetype?

[blakesmith]

Hey there,

I might be missing something in the documentation, but if I wanted to use the java server archetype (which generates its own upstart script), how can I specify custom JAVA_OPTS like my heap sizes? I've currently been using the java application archetype with my own init.d script while I figure this out.

Thanks for the plugin, it's been great for generating debian packages for deployment!

Blake

[jsuereth]

IIRC, the script should look for arguments in the /etc//

See:

1. https://github.com/sbt/sbt-native-packager/blob/master/src/main/resources/com/typesafe/sbt/packager/archetypes/bash-template#L330
2. https://github.com/sbt/sbt-native-packager/blob/master/src/main/scala/com/typesafe/sbt/packager/archetypes/JavaAppBashScript.scala#L42
3. https://github.com/sbt/sbt-native-packager/blob/master/src/main/scala/com/typesafe/sbt/packager/archetypes/JavaApp.scala#L39-L45

I think it's not actually exposed well, so for now the workaround to a nicer model is to do something like:

val configLocation = "$app_home/conf/my.conf"

bashScriptDefines <<= (Keys.mainClass in Compile, scriptClasspath, bashScriptExtraDefines) map { (mainClass, cp, extras) =>
      val hasMain =
        for {
          cn <- mainClass
        } yield JavaAppBashScript.makeDefines(cn, appClasspath = cp, extras = extras, config = Some(configLocation))
      hasMain getOrElse Nil
    }

Then, you should be able to place a default config file in src/universal/conf/my.conf. The format is one argument per-line, so something like:

-Xmx512M
-Xms128M
# Comments are ok too.

I'll try to get this exposed in a nicer fashion for the server archetype soon (Note: The archetype is still "experimental", but I'm happy so many people are helping refine it so quickly).

[blakesmith]

Great! Thanks for the detailed response, especially with a code sample. I'll give this a try and report back.

Cheers!

Blake

[magegu]

I would like to add an example to this ticket.
For our production server we need to add the following java opts (primarily for play/akka) to the upstart script. Since .bashrc etc are not read by the upstart script I was searching another way to get the parameters into the script.

JAVA_OPTS="-Dlogger.file=/home/ubuntu/conf/logger.xml -Dconfig.file=/home/ubuntu/conf/application.conf - Dhttp.port=disabled -Dhttps.port=9443 -Dhttps.keyStoreType=PKCS12 -Dhttps.keyStore=$SSL_PATH -Dhttps.keyStorePassword=$SSL_PASS"

[muuki88]

#121 almost fixes this issue for SystemV and with a minor change for Upstart as well. To add Java_Opts settings you just have to create etc-default under src/templates and put your Java_Opts as describe in it.

After #121 is merged I will change the method as describe by @jsuereth and add a setting bashConfigFileLocation which is by default /etc/default/<normalizedName>

This can be overridden with

bashConfigFileLocation := "/etc/yourapp/bootstrap.conf"

Note that this configuration is just for bootstrapping the application. Not for runtime.

[magegu]

@muuki88 thanks for the feedback. the etc-default will not work for setting passwords (since they should not be included in the repository) and as you mentioned the bashConfigFileLocation is not helping, either for the upstart problem.

any other suggestion how to pass env vars to the upstart script with the current code?

[aparkinson]

@magegu I add an empty bash config file to my packages and then use a configuration tool (Puppet or Augeas in my case) to insert production configuration/parameters into the file on disk after the package has been installed.

The Debian package knows the bash config file is used for configuration and won't overwrite your changes in the future when the package is upgraded

[muuki88]

I like @aparkinson approach. As @jsuereth mentioned in #121

Ok, so it looks like the two systems are actually using two different mechanisms of starting.

Right now the SystemV script is a complete script rather than just a wrapper to the BASH script we generate,
like upstart. Because of this, currently, they can't share the same /etc/default file. If someone who uses
SystemV could detangle that, we can make the default location for config /etc/default/<pkg> and then both
scripts will use it.

unfortunately, things like USER= wouldn't work for SystemV.

then we can use this for upstart, too.

[muuki88]

@kardapoltsev had a good idea in #134 . It should be really simple to specify java-arguments.

javaOptions in run := Seq("-Xms1024m", "-Xmx128")

All options in the bash-script fail:

• loadConfig

bashScriptConfigLocation := Some("/etc/default/ia-dashboard"),
debianMakeEtcDefault <<= (Keys.normalizedName, target in Universal, linuxEtcDefaultTemplate in Debian) 
map { (name, tmpDir, source) =>
            val scriptBits = TemplateWriter.generateScript(source, Seq.empty)
            val script = tmpDir / "tmp" / "etc" / "default" / name
            IO.write(script, scriptBits)
            Some(script)
},

and

-Xmx4098M
-Xms128M
-Dpidfile.path=/var/run/mukis-test.pid

• JAVA_OPTS env variables
• CLI options ./start-script -J-Xmx1024m

And I'm not really getting my head around, how the bash-template puts the commanline-call together. Something like

java $java_args -cp $classpath $app_args

would be useful. Tested with 0.7.M1.

[muuki88]

Okay, this setup actually works:

build.sbt

bashScriptConfigLocation := Some("/etc/default/mukis-test"),
debianMakeEtcDefault <<= (Keys.normalizedName, target in Universal, linuxEtcDefaultTemplate in Debian)
map { (name, tmpDir, source) =>
            val scriptBits = TemplateWriter.generateScript(source, Seq.empty)
            val script = tmpDir / "tmp" / "etc" / "default" / name
            IO.write(script, scriptBits)
            Some(script)
      },

/src/templates/etc-default

-mem 2048
-Dpidfile.path=/var/run/mukis-test.pid

[jsuereth]

cool. Maybe we need a constant for this:

bashScriptConfigLocation := Some("/etc/default/mukis-test")

So we aren't hard-coding that name, or we could just have the bash confg be the default for the server archetype.

[muuki88]

A default would be reasonable. The bash script takes care, if the file doesn't exists, so /etc/default/<normalizedName> could be set by the server archetype