Just to be a pain in the neck, is the dot separating "bar" and "xyz" in
the example intended to show that either a comma or a dot can act as
separators, or is that a typo?
Is there a way to specify on the use of the anno whether null should be
acceptable? Same for empty? With well-documented defaults, of course!
I am sure that if we try to choose one strategy and wire that in, then
the next day we'll discover a counter-example.
Any possibility to the list being looked up at runtime for values that
won't be known at compile-time?
- Tim
Byron Nevins wrote:
> There are 2 new Param annotation possibilities for AdminCommand's
>
> @Param(acceptableValues="foo,bar.xyz")
> String aString;
>
> aString will either be null, empty, foo, bar, or xyz
>
> If anything else is given then the command will fail at injection time
> -- before execute() is called
>
> /Call for comments -- should null and/or empty be errors?/
> ______________________
>
> @Param
> Boolean myBool;
>
> If the parameter is not given at all (i.e. no --myBool) then myBool
> == whatever you set it to in the declaration
>
> If the parameter is given -- this is how it works:
>
> null or empty string --> true
> case-insensitive match of "true" --> true
> case-insensitive match of "false" --> false
> anything else --> fatal error. AdminCommand.execute() will NOT be called
>
> If you have developed an AdminCommand that uses boolean options, I
> urge you to change to the new capability above.
>
>
> --
> Byron Nevins Work 408-276-4089, Home 650-359-1290, Cell 650-784-4123 - Sun Microsystems, Inc.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net For
> additional commands, e-mail: admin-help_at_glassfish.dev.java.net