This is something that would be pretty easy to change in the config
layer but I am a little scared about possible regressions by changing
this now. I am surprised we did not have that raised before !
Kedar, I know everything can be potentially tokenized but realistically
how much do we have tokenized right now (i.e. who will be potentially
impacted by a change a behaviour).
I think the safest of course is to keep the current behaviour and change
it post release if we can. There is a service that be can be used by
config listeners to translate raw values.
jerome
Tim Quinn wrote:
> Kedar Mhaswade wrote:
>> Tim Quinn wrote:
>>> If the user changes a config value (I tried using the admin console)
>>> that contains a token (such as ${com.sun.aas.instanceRoot}) then the
>>> event delivered to the "change" method returns the untranslated old
>>> and new values, still containing the tokens.
>>>
>>> Maybe this has been discussed before and I've forgotten... Is there
>>> something the "change" method can do to translate the values? It
>>> seems that the injected configuration object has already been
>>> updated with the translated new value. Is that expected and reliable?
>>> Thanks.
>>
>> Tim,
>>
>> Incidentally, I had some conversation with Jerome on this just yesterday
>> and I think it is an issue.
>>
>> IMO, The config layer should already resolve (expand) the variable in
>> the configuration object given to the changed method in ConfigListener
>> so that the runtime code does not have to do anything there.
> That's how it is now...at least that's what I saw.
>>
>> Alternatively, the variable expansion is just doing a replacement from
>> system properties. So in the changed method, if a particular attribute
>> contains {xxx} you could replace it with System.property(xxx). I have
>> tried it and it seems to work.
> I know that the changed method accepts a
> java.beans.PropertyChangeEvent argument. If only it were an
> org.jvnet.hk2.config.PropertyChangeEvent we could have exposed
> getRaw[Old | New]Value methods, for example. Maybe there could be a
> utility method so this could be implemented once instead of in each
> ConfigListener?
> This would be especially helpful if, as Lloyd said, the translation
> should include the <system-property> settings - or are those already
> set so they are accessible via System.getProperty()?
>>
>> I am going to spend some time on making the injected configuration
>> object have the variable-expanded values though.
> But it seems to do that already. Am I missing something?
>
> - Tim