admin@glassfish.java.net

Re: options that take a list of values

From: Bill Shannon <bill.shannon_at_sun.com>
Date: Fri, 28 Aug 2009 16:57:26 -0700

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?