Hi I guess you want to use an alternative backend to the filesystem (a database for instance).
In that case we have a Jira about that and you can provide your own persistence backend. Regards JB On Oct 6, 2017, 12:30, at 12:30, t...@quarendon.net wrote: >I'm trying to establish some alternative configuration behaviour than >what felix-fileinstall gives me. >I have written a very simple component that reads configuration files >in from /etc and updates config admin with the information, much like >fileinstall does. I can run this and it appears to work, however I >still have the existing mechanism in that I'd like to remove. > >So I naively did the following: > set the start-level of my bundle to be 11, same as fileinstall >set felix.fileinstall.enableConfigSave to false in >etc/custom.properties > set felix.fileinstall.dir to empty > >Karaf fails to start. > >So my suspicion is that apache fileinstall is more centrally required >than I'd hoped. Looking at the karaf code there are certainly a few >places where it assumes a configuration contains a >felix.fileinstall.filename property that names the file where the >configuration is stored, and seems to directly read and write those >files. This appears to mean that I wouldn't be able to substitute my >own configuration storage backend, which is a shame (I'm actually >confused what org.apache.karaf.config.core.ConfigRepository is actually >doing here -- why does is write directly to the file, rather than just >letting fileinstall do it, especially as it only seems to allow for >".cfg" and not ".config" files). There may be other reasons why karaf >won't start though. > >Is it likely that I would substitute felix.fileinstall in this way? > > >What I was actually trying to solve was what to do when a user >uninstalls and reinstalls our karaf-based product, and attempting to >preserve any configuration changes. What I had hoped to do was store >any actually modified configuration properties in separate files (just >the actual properties that were different from default or from the >originals in the etc/*.cfg files), so that the original etc/*.cfg files >would be replaced without difficulty, and the changed configuration >changes would then be applied. > >So alternative question: How else can I achieve the same thing without >making the users manually merge the configuration changes? > >Thanks.
