My opinion is based on the assumption that colons are more
common in "values" than commas are.
> I like Option 1 - seems most flexible option...every command will have
> an option to specify (rather override) its separator character. Trying
> to form any rules around usage of separators I feel renders it
> unintuitive and inflexible. If we go with annotations, default values of
> say a comma or a semicolon could always be assumed.
You mean some commands use commas and others use options depending upon
command implementations? That's rather non-uniform.
I like 2) mainly because it removes the problems with ':' especially
it comes to JVM options. e.g. I think
create-jvm-options -Xshare:on, -Xmx1g
is more usable than:
create-jvm-options -Xshare\:on:-Xmx1g
>
> 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
>