On Apr 7, 2009, at 11:06 AM, Lloyd Chambers wrote:
> No, AMX always returns the RAW value. This is crtiical, because
> otherwise setX( getX() ) would destroy things.
>
i.c. makes sense, forgot about that.
we should probably do the same with REST then.
jerome
> 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
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>