Pushed commits to release/jon3.1.x branch to handle quotes.

commit hash: 522ff41ba7
commit hash: 5e88634033d

JON 3.1.1 ER1 build is available. Moving to ON_QA.

https://brewweb.devel.redhat.com/buildinfo?buildID=226942

Works correctly for indexed arguments, failed for named argumets.
Script:
for (i in args) {
     println('args[' + i + '] = ' + args[i]);
}
println("start;"+ x + ";end");
println("start;"+ y + ";end");


exec:
exec -f scripts/start-web-app-instance.js --args-style=named x=1 y=2

output:
args[0] = 1
args[1] = 2
start;1;end
start;2;end

OK

exec:
exec -f scripts/start-web-app-instance.js --args-style=named x="aa" y="bb"

output:
args[0] = null
args[1] = null
args[2] = null
args[3] = null
start;null;end
start;null;end


fail

I have pushed a commit to the release/jon3.1.x branch to address the issues with parsing quoted strings in named arguments.

commit hash: e5d912de85a

I want to make it very clear that I am not entirely comfortable with making this change because there are more fundamental problems with the parsing as well as with the built-in commands, e.g., exec, login, logout, etc. You can invoke rhq-cli.sh to run a script in non-interactive mode as follows,

$ rhq-cli.sh -f myscript.js --args-style=named x=foo y=bar

We use a Java version of the Getopt library to parse the command line. This enables us to provide a command line interface for passing arguments and options that is consistent with most other unix/linux command line utilities and programs. When running in interactive mode, we would execute the above command line as,

$ exec -f myscript.js --args-style=named x=foo y=bar

We use the same Getopt parsing for the command line in the interactive shell. There is a fundamental problem here. The interactive shell is *supposed* to be a JavaScript shell with RHQ extensions that come in the form of additional objects and functions; however, it is not a 100% JavaScript. If it were 100% JavaScript, the interpreter would complain that foo and bar are undefined, but we instead treat foo and bar as literal strings. Let me illustrate the problem here with another example (assume that myscript.js just prints the value of x). 

$ myvar = "my var"
$ exec -f myscript.js --args-style=name x=myvar

The script will output the string "myvar, not "my var". This means the value of a named argument cannot be any valid JavaScript expression; however that is what should be supported. 

I described what I firmly believe is the most appropriate solution here https://bugzilla.redhat.com/show_bug.cgi?id=824129#c4. Earlier I mentioned that there are several "built-in" commands including exec, login, and logout. What exactly do I mean by that? Those commands are built directly into the CLI's interactive shell. When you execute a statement in the interactive shell, it is parsed to see what built-in command to execute. If the statement is,

$ logout

Then the appropriate Java method is invoked to perform the logout action. If the statement is something like,

$ myVar = {x: 123, y: function() { return "love craft beer";}}

That statement will be passed directly to the JavaScript interpreter since there it does not contain a built-in command. But if the statement is,

$ exec myVar = {x: 123, y: function() { return "love craft beer";}}

The appropriate Java method is called to parse the statement. In this case, the bulk of the parsing is handled by the JavaScript interpreter. But if we do,

$ exec -f myscript.js arg1 arg2

We execute the same parsing logic that is used to parse and execute scripts from the bash shell via rhq-cli.sh. When you run a script in non-interactive mode, the script is passed directly to the JavaScript interpreter. Because of these inconsistencies, we have functionality available in the interactive shell that is not available in non-interactive mode, namely the exec command. This has all led to hard to maintain, buggy code.

The solution is rather straightforward. We need to do away with these commands that are built into the CLI shell. They should be replaced with objects and/functions that are available in the script bindings. This has some major benefits. First, we can eliminate this error-prone parsing that we do in the interactive shell. The parsing can be handled by the JavaScript interpreter. Secondly, the environment will be consistent across both interactive and non-interactive modes. Thirdly, everything is standard JavaScript (or any other supported scripting lang) which means users do not have to learn or understand any additional syntax. 

So instead of an exec command, we would provide an exec function (that is properly name spaced) that might be used as follows,

$ exec("myscript.js", arg1, arg2)

Since JavaScript does not support named arguments we can do,

$ exec("myscript.js", {namedArg1: "foo", namedArg2: "bar"})

No extra, special parsing required. It's all just standard JavaScript.

Part of comment 4 needs a bit of clarification. I said that I was not entirely comfortable with the change because it addresses this specific issue and not the broader issues which I described in greater detail. I have tested the changes locally and am confident that they fix the problems described in comment 3. As for the broader, more fundamental issues, those would likely come in a major release. I will raise a separate bug for these other issues after discussion on the community mailing list (rhq-devel).

Moving to ON_QA. The JON 3.1.1 ER3 build is available at https://brewweb.devel.redhat.com/buildinfo?buildID=230321.

Verified on JON 3.1.1 ER3

Bulk closing of old issues in VERIFIED state.