There are several commands that have options that take a list of values.
In some cases the list elements are separated by comma and in some cases
the list elements are separated by colon. The server side gets these
list parameters and separates the elements, storing them into the command
implementation class.
The --properties option is represented by a Properties field in the command.
The parameter processing code can always separate these elements using colon.
Two examples...
create-connector-security-map has a --principals option where the
principal names are separated by commas.
create-file-user has a --groups option where the group names are
separated by colon.
Currently the parameter handling logic is only using colon to separate
such lists. Without additional metadata, it's impossible to know whether
a particular option should be separated by comma or colon. (Since the
type of the field is List<String> in both cases, there's no way to distinguish
the cases.)
As far as I can tell, the complete list of commands with comma separated
options is:
create-connector-security-map
update-connector-security-map
update-connector-work-security-map
The complete list of commands using colon as a separator is:
create-file-user
update-file-user
There seems to be three obvious ways to fix this:
1. Add the additional metadata, either as yet another element in the @Param
annotation, or as a @Separator annotation that's used in combination with
the @Param annotation. (Updating ParamModel accordingly.)
2. Accept either comma or colon in all such cases. The first comma or colon
would determine the separator used for the rest of the string.
3. The generic parameter handling logic can always use only colon (or only
comma; we decide). Commands that need a different separator can change
the type of the field from List<String> to String and then do the token
splitting internally to the command.
Anyone have an opinion as to which is preferred?