Unclear behavior with ConfigurableService.factory attribute

[splatch]

At present it is possible to use configuration framework to describe service config options. One of attributes which can be set for configurable service is factory which implies "multiplicity" of these.

Looking at the sources this attribute is currently used in very few places with fairly strange attitude. The configuration part of framework is intended to cover OSGi ConfigurationAdmin and its behavior with ManagedService and ManagedServiceFactory. Yet I have impression that current logic fails to detect managed service factories and their sub-configurations.

I found this while trying to make UI render properly multiple service coming from same factory but different configurations.

[splatch]

Looking closer at how it is implemented it is worse than I thought.. ConfigDispatcher is supposed to copy configs between folders and create factory configurations based on first line of file itself (so called service context) and then push it into configuration admin using oh.servicecontext config property (esh.servicecontext in the past).

This really seem to be an workaround for OSGi 4.2 specs which could not identify managed configurations and assigned random identifiers. Given that this feature is not widely adopted and we have recent spec (not one inherited from ESH) it would make sense to utilize new functionality in combination with Felix Fileinstall instead of config dispatcher.

[splatch]

According to this issue https://issues.apache.org/jira/browse/KARAF-6676 - if filename contains ~ instead of - then it is a named configuration with OSGi R7 (https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.cm.html#i1761778) which is available from Karaf 4.3.0 onwards. This is the version used in OH 3.1 milestones.