3

I have an application that requires me to set a system property during startup, and the property must be different in each environment (i.e. one value in Dev, a different value in Prod).

This is similar to another unanswered question, but that one asks specifically about daemons, and we are using Program scripts. The solution may be the same, though I did find hints that there may be special treatment for JSW daemons. The unix template has a placeholder for @ENV_SETUP@, and the documentation says that environmentSetupFileName is for JSW only. I would consider using environmentSetupFileName, but I can't find any more information on how to use it or how to get other scripts in the bin directory where environmentSetupFileName expects them to be.

This seems like it must be a common problem, and I'm surprised the answer isn't easier to find. How can I set environment-specific system properties with AppAssembler?

Community
  • 1
  • 1
datguy
  • 623
  • 8
  • 24
  • If anyone is interested, our solution to this problem was to remove everything from the AppAssembler configuration that varied by environment. Instead, we use a system property at runtime to determine which environment we are in, and load property files based on that value. – datguy Jul 17 '14 at 17:43

2 Answers2

1

You can put the environment variables inside extraJvmArguments, something like

<extraJvmArguments>-Dapp.contextPath=${APP_CONTEXT_PATH}</extraJvmArguments>

since APP_CONTEXT_PATH cannot be resolved during packaging time, it will remain in this form in the script generated by appassembler.

Then just set this env variable during deploy. This is very handy if you use docker.

Wei Qiu
  • 886
  • 9
  • 16
0

First I have to say your assumption that the environment setup file is only for JSW is simply not correct. The doc says:

Setup file in $BASEDIR/bin to be called prior to execution.

Note: only for the jsw platform. If this optional environment file also sets up WRAPPER_CONF_OVERRIDES variable, it will be passed into JSW native launcher's command line arguments to override wrapper.conf's properties. See http://wrapper.tanukisoftware.com/doc/english/props-command-line.html for details.

The notion of JSW is only related to the Note which means you can define special variables to override the wrapper configuration files. I think this should be improved (created a ticket for that).

The definition of the environment setup file is only to say that the generated scripts will call that given setup file. If you like to add other files into the bin file than it's your turn.

Furthermore if you understand your requirement correct you need to create different packages Dev, Prod etc. where the values are different. This means you need to create a package for Dev and a package for Prod. This means several executions for appassembler-maven-plugin etc. and may be maven-assembly-plugin to create an appropriate archive of the result.

Community
  • 1
  • 1
khmarbaise
  • 92,914
  • 28
  • 189
  • 235
  • Separate packages for each environment is one solution, but it sounds like overkill. All I need are separate properties for each environment (e.g. system properties and property files). There is value to deploying the same binary as we progress through the environments, and only changing configuration. – datguy Feb 11 '14 at 17:55
  • To your point about adding files to the bin directory - how would I do that? I haven't found the right set of mojo to copy files into the bin directory after it is created by the AppAssembler plugin. – datguy Feb 11 '14 at 17:58
  • Just use maven-assembly-plugin to package the bin folder and add supplemental files via assembly-descriptor. I wouldn't copy them into the bin folder just use the descriptor to package them into the resulting archive. – khmarbaise Feb 11 '14 at 17:59