Define a generic runtime service holding properties

(follow up of NXP-17673, to make the feature more generic)

Problems we want to solve

More and more configuration properties are added to be made customizable from the nuxeo.conf file, but:

• documentation is painful
  • properties are only documented in Confluence (see https://doc.nuxeo.com/x/QQA7)
  • properties are never attached to a specific service context
• nuxeo.conf, that was supposed to be a “deployment oriented” config, ends up being an application level config – this makes it not very clean to package
• these "application configuration properties" cannot be easily set from Studio (using an XML extension)

Current Status about configuration

Why are we in this situation

In an ideal world, all “application level” configurations should be handled by an extension point of the target Component :

• this would give good context for the configuration
• this allows for easy merge / override

However, there are several problems that prevent this :

• Sometimes we do not have any component at all (a typical example would be the JSF layer)
  --making a Component / Service / Extension point just to have one value configurable is overkill
• Sometimes we have a Component but creating an extension point seems overkill too
  • more work
  • potentially more backport (a lot of properties are actually introduced for support requests)

Contextual information

NXP-17673 introduced a JSFConfigurationService to handle the problem for the JSF related variables that can be used after the Runtime is started (other variables will need to remain in {{nuxeo.con}}f for now).

The point is that this service has nothing specific to JSF and could be used more widely by other parts of the framework.

Make the ConfigurationService generic

Creating multiple ConfigurationService implementations does not really make sense, it seems better to have one centralized ConfigurationService that would be part of Nuxeo Runtime.

The idea would be to use this service :

• instead of nuxeo.conf when the parameter is “application level” and not “deployment level”
• only if there is no candidate component to host this via an extension point

Here is a sample configuration, adapting examples from NXP-17673

<component name="org.nuxeo.runtime.ConfigurationService">

  <implementation
    class="org.nuxeo.runtime.services.config.ConfigurationServiceImpl" />

  <service>
    <provide interface="org.nuxeo.runtime.services.config.ConfigurationService" />
  </service>

  <extension-point name="configuration">
    <object class="org.nuxeo.runtime.services.config.ConfigurationPropertyDescriptor" />
  </extension-point>

</component>

Default contribution:

<component name="org.nuxeo.ecm.platform.ui.web.configuration.default">

  <extension target="org.nuxeo.runtime.ConfigurationService"
    point="configuration">

      <property name="nuxeo.jsf.enableDoubleClickShield">true</property>

  </extension>

</component>

Note that expressions like ${nuxeo.jsf.enableDoubleClickShield:=true} are still useful with this service: it will not retrieve the property value from the nuxeo.conf file first (if defined there), it will only lookup the property value held by the service (but will issue a warn at prop registration if prop is defined in nuxeo.conf)