Sankar is right on why we choose different separators.
I like option 2, we can be backward compatible this way.
Sankar Neelakandan wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>