admin@glassfish.java.net

Re: options that take a list of values

From: Byron Nevins <Byron.Nevins_at_Sun.COM>
Date: Fri, 28 Aug 2009 17:51:54 -0700

So -- you were expecting a bunch of programmers to agree on something?
I'm amazed we all agreed to use spaces instead of tabs in source code!
;-)
Bill Shannon wrote:
> Well, this has been fun! :-)
>
> The votes are pretty much all over the map. There's no clear consensus.
> So, since Jerome is the v3 architect, I talked to him about it. His
> preference is option #1, so that's what I did.
>
> @Param will have a new "separator" element, with a default value of ','.
> Commands that have Properties options will need to override the default
> to use ':'. I'll change the following commands to do so:
>
> connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/CreateAdminObject.java
>
> connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/CreateConnectorConnectionPool.java
>
> connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/CreateConnectorResource.java
>
> connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/CreateConnectorWorkSecurityMap.java
>
> connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/CreateConnectorWorkSecurityMap.java
>
> connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/CreateCustomResource.java
>
> connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/CreateJavaMailResource.java
>
> connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/CreateJndiResource.java
>
> connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/CreateResourceAdapterConfig.java
>
> connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/UpdateConnectorWorkSecurityMap.java
>
> connectors/admin/src/main/java/org/glassfish/connectors/admin/cli/UpdateConnectorWorkSecurityMap.java
>
> core/kernel/src/main/java/com/sun/enterprise/v3/admin/CreateAuditModule.javacore/kernel/src/main/java/com/sun/enterprise/v3/admin/CreateMessageSecurityProvider.javacore/kernel/src/main/java/com/sun/enterprise/v3/admin/CreateProfiler.java
>
> core/kernel/src/main/java/com/sun/enterprise/v3/admin/CreateSystemProperties.java
>
> core/kernel/src/test/java/com/sun/enterprise/v3/admin/CommandRunnerTest.javadeployment/admin/src/main/java/org/glassfish/deployment/admin/CreateLifecycleModuleCommand.javajdbc/admin/src/main/java/org/glassfish/jdbc/admin/cli/CreateJdbcConnectionPool.javajdbc/admin/src/main/java/org/glassfish/jdbc/admin/cli/CreateJdbcResource.java
>
> jms/admin/src/main/java/org/glassfish/jms/admin/cli/CreateJMSDestination.javajms/admin/src/main/java/org/glassfish/jms/admin/cli/CreateJMSResource.java
>
> jms/admin/src/main/java/org/glassfish/jms/admin/cli/ListJMSDestinations.javaorb/orb-connector/src/main/java/org/glassfish/orb/admin/cli/CreateIiopListener.javasecurity/core/src/main/java/com/sun/enterprise/security/cli/CreateAuthRealm.java
>
> web/admin/src/main/java/org/glassfish/web/admin/cli/CreateHttpListener.java
>
> web/admin/src/main/java/org/glassfish/web/admin/cli/CreateVirtualServer.java
>
>
> In addition, I'll change the create-file-user and delete-file-user
> commands.
>
> Commands that are doing their own tokenization, such as the deploy Hong
> mentioned, shouldn't be effected, although the owners of those commands
> are encouraged to change the implementation to use List<String> instead
> of String and let the framework do the work of splitting the values.
>
> No doubt there will be something I miss in a change this far-reaching.
> If you notice any problems, let me know. Or better yet, just fix it!
>
> Oh, and in case it's not obvious, all of the above commands that are
> currently using colon as the separator, and are thus incompatible with
> v2, will be fixed to be compatible with v2, which might break any scripts
> or tests that are relying on the broken v3 behavior. If you know of
> anything that will be effected, please fix it!
>
> This message is just a heads-up. I'll send a message to dev_at_glassfish
> when I commit the changes.
>
>
>
> Bill Shannon wrote on 08/28/09 12:31:
>> 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
>