We had an interesting conversation on IRC earlier today and I thought I'll
remind sipXconfig contributors about @SettingEntry annotation

It is a convenient mechanism used to intercept setting value resolution. It
allows you to calculate the value of the setting based on the current
configuration of the system. Let's say your component has a
YET_ANOTHER_DOMAIN_NAME setting that represents SIP domain name. If you
store the domain name value in this setting directly, you'll have to update
it every time the domain name is change. However if you intercept the value
resolution for YET_ANOTHER_DOMAIN_NAME you can just query DomainManager for
the current value whenever you need.

There are currently about 250 places in the code where it is used (so there
should be many examples to choose from) but most of them related to phones
and gateways.

And the wiki only mentions it in the context of phones:
http://sipx-wiki.calivia.com/index.php/Adding_support_for_managed_phones#Line_Runtime_Defaults

But there is nothing phone/gateway specific about it. Use it in any place
where settings are used (in any BeanWithSettings or BeanWithGroups).

What you need to do it to register bean setting handler for your bean
class. It's usually done in initialize method:

class MyBean extends BeanWithGroups {
...
    @Override
    public void initialize() {
        addDefaultBeanSettingHandler(new MySettingsHandler(this));
    }


And then, annotate the getter in MySettingsHandler

class MySettingsHandler {

    @SettingEntry(path = "general/domain")
    public String getDomain() {
      return m_domain_manager.getDomain().getName();
    }

}


If someone (usually the code the generates configuration for MyBean) tries
to retrieve the value of "general/domain" setting,
MySettingHandler.getDomain is going to be called to calculate it.

The nice thing is that the MySettingHandler does not have to conform to any
special interface. You can inject it with whatever you need to calculate
value that interest you. You can register more than one handler if you have
disjoint set of settings that you need to calculate.

Recently there is a new category of settings enabled beans in sipXconfig:
all the sipx services are represented as SipxService since sipXconfig is
now responsible for generating configuration for them. I hope you'll find
@settingEntry mechanism useful when working on SipxService(s).

If you want to find our how the machinery underneath works check
BeanValueStorage class.

Damian

_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev

Reply via email to