System properties not working in Ash Script

[aserrallerios]

This PR broke the feature and was integrated into 1.1.0:

#766

Simply placing $@ before the $app_mainclass fixes it. An example of fully working command line would be (using latest version as template):

    exec java -classpath $app_classpath "$@" $opts $java_args $app_mainclass $app_commands

$app_mainclass and $app_commands must be placed after all arguments (both JVM & system properties), otherwise it won't work. This is simply how java command works.

Unfortunately we really don't know what the motivations of @dhoepelman were on that PR.

[muuki88]

I guess the confusion comes from the way loadConfig works. The problem is that you can write java options and application arguments into the config file.

So the first change

# if configuration files exist, prepend their contents to $@ so it can be processed by this runner
[ -f "$script_conf_file" ] && set -- $(loadConfigFile "$script_conf_file") "$@"

java -classpath $app_classpath "$@" $app_mainclass

was working if you put app arguments in the config file. The second change by @dhoepelman fixes the argument problem by putting the config content in a separate variable $opts. However this breaks if the config fail contains application arguments.

# If a configuration file exist, read the contents to $opts
[ -f "$script_conf_file" ] && set -- $(loadConfigFile "$script_conf_file") "$opts"

java -classpath $app_classpath $opts $app_mainclass $@

The bash script has logic implemented to separate java options from application arguments. This is missing the ash script, why every change will break something else.

In order to fix these, we need to mimic this behaviour.

[NeQuissimus]

Is this also covered by #866 and friends?

[muuki88]

Unfortunately not. The logic separating java and application arguments is still missing