Yes, escaping would work, but it would only be *necessary* for the first
colon or comma that wasn't intended to be a separator.
That is...
a,b:c,d would result in "a", "b:c", "d"
a\,b:c,d would result in "a,b", "c,d"
June.Parks_at_sun.com wrote on 08/28/09 12:50:
> I like option 2. There may be rare cases where both a colon and a comma
> occur in a string, but I'm assuming that the character that isn't the
> separator could be escaped.
>
> June
>
> On 08/28/09 12:31, 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
>