Just as an update, this is what I've ended up doing, at least for a PoC. I struggled for a while to try and completely remove fileinstall. I'm sure it's probably possible, but in the end it was easier to "move it out of the way". In custom.properties, I set: * felix.fileinstall.enableConfigSave to stop it trying to write config files back * felix.fileinstall.dir to a bogus directory to stop it trying to read config in. This works OK, as long as you set: * felix.fileinstall.disableNio2 to true to make is use "simple" recursive directory scanning. Without this it tried to create a nio2 watcher service which fails due to the bogus directory. This failure is caught and then the code falls back to the non-noi2 version, so setting this just avoids that happening. * felix.fileinstall.noInitialDelay to false to avoid it doing an initial scan, which again would fail due to the bogus directory. * felix.fileinstall.poll to a very large number to avoid it doing a subsequent scan.
I then created my own startup bundle and set the start level to the same value as was used for fileinstall. In this bundle I did my own initial read of the etc directory and loaded the configuration properties into ConfigurationAgmin. This is enough to get karaf to then start. I then created my own implementation of the felix configadmin PersistenceManager implementation and registered it as an OSGi service with the "name" property. I then set the felix.cm.pm system option in custom.properties to that name. This gave me a working basis for experimentation. Configuration properties are loaded initially, and then modifications are saved. You may be able to get away with the initial load of the cfg files and rely totally on the PersistenceManager, but I haven't been totally successful with that. You'd think it ought to work. As it is you get a slightly curious situation where you load the config files in and the PersistenceManager gets asked to save them again. The early start level causes some problems, you can't use declarative services, depending on other bundles such as json or yaml is slightly problematic, but otherwise this works fine. Assuming you can get over the early start level I don't see why writing to a database wouldn't work, but I've just been interested in reading and writing to files in a different way.
