> asadmin some-command ... --enabled=${ENABLED}
> domain.xml will record ${ENABLED} as the value of that setting
I have a question here. So, in domain.xml, as Admin Console is still
using AMX to get the value of this enabled attribute, will it return
${ENABLED} or the translated value ? And if later when the REST API
is available, what will be returned ?
I hope i don't need to worry about having to resolve every single
attribute returned.
thanks
Anissa.
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
>