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
>