No, AMX always returns the RAW value. This is crtiical, because
otherwise setX( getX() ) would destroy things.
AMX offers explicit resolve...() methods.
Lloyd
On Apr 7, 2009, at 8:50 AM, Jerome Dochez wrote:
>
> 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.
> AMX and REST always return the translated values.
>
>>
>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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