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.
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
>