geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jinmei Liao <>
Subject Refactor gfsh parser
Date Thu, 20 Apr 2017 20:37:57 GMT
In the effort of adding option validation to gfsh commands (GEODE-1597) and
simplifying gfsh parsing, I started this exercise of only using
SpringShell's parser instead of a combination of springshell's,
joptsimple's and our own parsers. The end result is a lot more manageable
code base,  and the capability to validate the option list, but does have
these following different behaviors, and I would like the community's wight
in on whether or not these are acceptable or not:

1) SpringShell doesn't allow you to specify an option twice, so for
multivalued parameters, our old parser can accept command like

"change loglevel --member=member1 --member=member2",

but now the parser will give you an error, and you should only do
"change loglevel --member=member1,member2".

The new parser did something speical for --J option though, so for --J, you
can specify it multiple times.
2) For value separator, springShell default's to ",", you can only
overwrite it with option context "splittingRegex", we do not honor the
@CliMetaData(valueSepartor=) anymore. All of our commands uses "," for
separators, so this won't break our commands, but if there is any command
out there that would define a different @CliMetaData(valueSepartor=) other
than ",", SpringShell would not know how to parse it.
3) To specify empty string as parameter value, before you will need to do

put region=A key="''" value="''"

spring shell would think the value you are trying to pass in are two single
quotes instead of empty strings, now, you should only do

put region=A key="" value=""



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message