Have you considered allowing such things as *operands*? Then space is
the separator.
Lloyd
On Aug 28, 2009, at 12:31 PM, 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
>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team