Lists of thing are complex, so take away the complexity.
Syntax compliant to CLIP which uses operands. The "--" means "end of
options":
create-jvm-options -- -Xfoo=bar -abc -Dbar=far
Better IMO, but I realize a really complex command which needs
multiple lists of things could have an issue here.
Lloyd
On Aug 28, 2009, at 1:24 PM, Kedar Mhaswade wrote:
> 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
>
>
> ---------------------------------------------------------------------
> 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