I can see KARAF-418, but that's pretty old, and sounds like it was considered unnecessary? Is there anything else I can't find?
I don't necessarily want to store things in a database, I just want different behaviour to normal, to provide my own implementation of something that listens to config changes and injects configuration on startup. And I can write that bit, what I can't do is substitute it in at a central enough level to replace fileinstall. I've made a little progress. I manually edited the "startup.properties" file and put my bundle in there at level 11. It got activated. So what I don't currently understand is a) where that file comes from (it's clearly generated as part of building my karaf distribution, it's not in source control) and b) what specifying the start-level in the feature.xml file does (since it doesn't appear to specify the start level :-)). My problem now appears to be that I'd written my code using declarative services, and I think I need to go back to old fashioned bundle activators and service trackers in order to reduce the dependencies and make the code work in the "simple" environment I encounter down at that start level. There was also a comprehension question of why the ConfigRepository was attempting to write the config files directly, rather than just calling Configuration.update. Surely one thing or the other (calling update I assume is preferable), but not both? Thanks. > On 06 October 2017 at 11:40 Jean-Baptiste Onofré <[email protected]> wrote: > > > 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, [email protected] 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.
