@kcollins1 ( most likely person to know and answer 
)
In the manual, it says:
Wrapper arguments (starting with wrapper.* ) will be merged ... to those specified in the ignition.conf file.
Looking in the file in a running docker container, I can see that these wrapper.additional options are already there:
# Java Additional Parameters
wrapper.java.additional.1=-Ddata.dir=data
wrapper.java.additional.2=-Dedition=
So, if I wanted to adjust ignition.projects.scanFrequency does it matter which number I put after wrapper.java.additional? If I use
wrapper.java.additional.1=-Dignition.projects.scanFrequency=10
in my docker command line options will it blow away the -Ddata.dir=data option?
You don't need to use a wrapper prefix; you can directly specify the option after the double hyphen:
--
-Dignition.allowunsignedmodules=true
-Dia.developer.moduleupload=true
Then you don't need to worry about "merging" with the service file.
Any wrapper specific properties I would expect the command line passed value to "trump" the value in the file, which you could use to override.
1 Like
That seems really obvious in hindsight. I was so caught up on how I specify that option in the ignition.conf normally that I didn't back up and notice the other method staring me in the face. Thank you!
I'll offer some supplementary information in the event that anyone is curious as to what mechanism is being used to feed in these supplementary JVM args.
We collect the arguments in our entrypoint script and write them to a temporary file during launch of the container, e.g. .ignition-jvm-args.<8 random chars>. It might have contents like below (for Paul's example):
#encoding=UTF-8
-Dignition.allow.unsignedmodules=true
-Dia.developer.moduleupload=true
This file is then supplied via wrapper.java.additional_file when we launch the wrapper (and thusly Ignition). See those linked docs for details on how the applied arguments behave (hint: Paul is right).
Here is a small illustration because pictures are nice:
4 Likes
