Hi,
I am currently wrappifiying an external application. This is tomcat based and defines several things in setenv.sh by setting the CATALINA_OPTS environment variable.
When using the service wrapper the setenv.sh is normally useless. Actually I have to analyze the setenv.sh and translate all relevant stuff to wrapper.conf. The result is automatically packed. If we do an update of the application normally we just replace a zip file. If something has changed in setenv.sh it is very likely to be forgotten and the translation is a little bit error-prone.
I would like to have the settings from CATALINA_OPTS (and perhaps other VCariables) as defaults with the ability to overwrite them in wrapper.conf
I tried to first call the setenv.sh in the wrapper-staring-script and then take something like wrapper.java.additional.1=%CATALINA_OPTS%
This does not work as the argument of wrapper.java.additional may only contain one setting.
I found the wrapper.java.additional_file (with content %CATALINA_OPTS%) but according to the documentation this is processed after all settings so I cannot overwrite something which has already been defined.
I would suggest one of the following:
Then we could leave manufactor-defaults untouched with the ability to explicitly overwrite them.
Michael,
The _file properties were designed to handle cases like you are asking for.
But it sounds like they don't quite meet your needs:
http://wrapper.tanukisoftware.com/doc/english/prop-java-additional-n.html#file
http://wrapper.tanukisoftware.com/doc/english/prop-app-parameter-n.html#file
Would it be possible to write the _file as part of the script used to install the service?
A lot users make use of the include files to specify a user file which can be used to override any property defined earlier. Properties defined in the main file after the include could thus not be overridden as the Wrapper always uses the last declaration of any property.
http://wrapper.tanukisoftware.com/doc/english/props-cascading.html
Environment variables of course have a scope, and something defined in your startup script will not exist when the Wrapper is run later as a service.
Are you wanting to be able to override JVM or app arguments based on their values if a specific argument is redefined? The Wrapper does not currently parse those values at this level. Although that could be a possible feature for the future.
Could you please give me an example of what you are wanting to do? I want to make sure I am clear on the issue.
Cheers,
Leif