Jerome Dochez wrote:
> 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).
Yes. I should have clarified that. The variable substitution facility is
available to domain.xml only, AFAIK. So, this applies to those @Params only.
The question is whether we should enforce it or not. Enforcing it makes
it consistent, but harder to implement generically, especially for booleans.
I will ask this question in engineering meeting later today.
-Kedar
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>