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()?
Yes, but I think that should not be done by the change receivers. It's
a work-around for now. Can you try it and let me know if it works for you?
>>
>> 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?
If let's say you have a listener as the object you get in changed
method, listener.getPort() will return something like "${PORT}"
instead of the resolved value of PORT, if a <system-property>
is defined. If there is no <system-property> named "PORT" is
defined setting the port attribute of this listener should itself
fail, but that is a separate issue which has a different resolution.
When you say it seems to do that already, do you mean in above case
you get the value of getPort() resolved as say "1234" (assuming
<system-property name="PORT" value="1234"/> exists)?
Also, note that all the other tokens like "com.sun.aas.instanceRoot"
are defined as plain Java system properties when server starts up.
>
> - Tim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>