I prefer option3 with comma as a separator. When we mention --properties
we separate name=value pairs by colon to denote different names and
different values. But in the case of single option name taking multiple
values, "," as the separator would be more meaningful. If "," is part of
the value we can always escape it.
thanks
Sankar
Bill Shannon wrote:
> 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?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>