IMO the parameters of a command have nothing to do with what will
eventually be saved in the domain.xml so it's fine to use Boolean and
Integer if those parameters are local to the command implementation.
If a parameter of a command happens to be saved directly to the
domain.xml then yes I think it's reasonable to enforce that they are
of the same type (ie String).
Jerome
On Apr 7, 2009, at 8:05 AM, Kedar Mhaswade wrote:
> Tim,
>
> I am sure sure how framework can handle this.
> This is because injection processing takes into account
> the type of fields/methods that are annotated with @Param. It's
> not clear to me how command can ask for untranslated value explicitly.
> By default, whatever the command line provided should be given to
> command
> implementation, as-is.
>
> Now, we can punt on all of it and say that if you wanted to use
> variable
> expansion, use the "asadmin set" method which allows strings.
> But then it would be a two-step process for a user. So, we have got to
> make a choice here. Certainly, I like typed injection, but I am just
> not
> sure how framework can handle it.
>
> This also casts doubts on
> public String acceptableValues() default "";
> field in @Param, because potentially, any value like "${...}" is an
> acceptable
> value.
>
> -Kedar
>
> PS - Note that all @Configured mutators are typeless. They only
> accept strings
> for this very reason.
>
> Tim Quinn wrote:
>> Kedar,
>> Kedar Mhaswade wrote:
>>> V3 asadmin command developers:
>>>
>>> It's important to note that non-String fields in your command
>>> implementation
>>> classes are not to be annotated with annotation @Param.
>>>
>>> This is to support the variable expansion (token) support we have
>>> for various values in domain.xml, for which options should be
>>> replaced
>>> verbatim.
>> If I understand correctly, you are saying that if I use
>> asadmin some-command ... --enabled=${ENABLED}
>> that domain.xml will record ${ENABLED} as the value of that setting
>> and not the translation of ENABLED at that moment. I certainly see
>> the value of that.
>> Yet when the command implementation class is invoked, hasn't the
>> framework already substituted the current value for the placeholder
>> as part of the injection processing (unless I've asked for the raw
>> untranslated value explicitly)? If not, it should.
>> And, if the framework can substitute the token's current value as
>> it injects the values into the command class, why not have the
>> framework also do the type conversion and error handling itself,
>> which ensures that it is done and done in a coherent and uniform
>> way? That would be preferable to depending on each individual
>> command implementation class to do each param conversion itself and
>> to detect and handle conversion errors nicely.
>> Just my US$0.02 worth.
>> - Tim
>> ---------------------------------------------------------------------
>> 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
>