Hi Jens,
I've take a look to the presentation and it looks really good. It helps a lot in understanding how the Configuration Service works.
The Configuration Service is not perfect but maybe I can help to understand some of its early design decisions.
1. We didn't trust the OSGi (at least the Equinox implementation) storage area for embedded applications. I don't have a direct experience but what I've been told by the original contributors is that it can become messy or corrupted and could prevent the
framework to start.
Hence the decision to always start OSGi in a clean state (osgi.clean=true).
2. This led us to find a way to persist the configurations outside of OSGi in snapshot files.
3. An special snapshot file, snapshot_0.xml, is used to provide an initial configuration which is useful also if the framework was started with osgi.clean=false
but there is no configuration yet in the OSGi storage area, for example at the very first boot.
The snapshot 0 can be different for every platform and allows to not
hardcode a default configuration in the components.
The Configuration Service has evolved since then to support new features and not always in the right direction. Everything can be improved.
Nonetheless I believe that reimplementing it would be an under-estimated effort.
I've discussed the Karaf issues with Marco and we can provide the following suggestions to make the Configuration Service compatible with the Karaf requirement of starting OSGi with
osgi.clean=false.
The Configuration Service will read the value of the osgi.clean property:
a. If set to true,
the Confgiuration Service nothing changes
b. If set to false and snapshot 0 is the only snapshot, the Configuration
Service will behave as above but it will save a new snapshot identical to snapshot 0
c. Otherwise, if snapshot 0 is not the only snapshot, the
Configuration Service will not read the latest snapshot and will assume that the configuration will be restored by the Configuration Admin from the OSGi storage area. Please note that typically Kura configures the storage area in a temporary filesystem that
may be wiped out on reboot.
The
path of the storage area is configurable.
The
above should work in the following cases:
i.
Very first boot when the OSGi storage area is clean and snapshot 0 is the only snapshot
ii.
Subsequent boots when the OSGi storage area has been populated and another snapshot exists (see b above)
iii.
If it happens that the storage area gets corrupted, you can set osgi.clean=true
and the Configuration Service will load the configuration from the latest snapshot which should be in sync with the last working configuration of the Configuration Admin.
All
this has a chance to work and maybe could be a reasonable short term solution to overcome the Karaf problems.
Ciao,
Cristiano