You could also look at the read-only implementation of ConfigAdmin we have in Karaf. That can easily be used to remove fileinstall completely, as done in the static configurations.
https://github.com/apache/karaf/tree/master/services/staticcm/src/main/java/org/apache/karaf/services/staticcm 2017-10-06 13:39 GMT+02:00 Jean-Baptiste Onofré <j...@nanthrax.net>: > Hi Tom, > > You can implement your own PersistenceManager (ConfigAdmin service). > > Regards > JB > > > On 10/06/2017 01:07 PM, t...@quarendon.net wrote: > >> 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é <j...@nanthrax.net> 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, 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. >>>> >>> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > -- ------------------------ Guillaume Nodet
