AMX has explicit resolve() methods, it always returns the raw value,
you have to resolve explicitly. This is obviously critical for the
GUI, which needs to display the unresolved value.
On Apr 7, 2009, at 8:45 AM, Anissa Lam wrote:
>
>> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team