I've implemented a SQL mechanism for persisting configurations. I started by trying to implement a custom persistence mechanism for Felix CM. This didn't work (see http://karaf.922171.n3.nabble.com/Custom-PersistenceManager-configurations-not-instantiating-components-td4052786.html#a4052799 ).
What I ended up doing was having a component which just interacted with Configuration Admin (creating configurations at startup; updating the database when modifications occur; deleting configurations at shutdown). File install is still running - it creates files when my component creates configurations, and updates & deletes them as necessary. The only downside I've found is the factory configurations get a new PID every time Karaf starts (as you can't specify the pid for a new factory configuration - though I understand this is possible in new versions of Config Admin). Paul On Wed, 13 Mar 2019 at 13:50, <[email protected]> wrote: > I'm trying to experiment with an alternative way of loading up > configuration. So my goal is to disable felix fileinstall and provide an > alternative implementation of the org.apache.felix.cm.PersistenceManager > interface. > > However, so far I'm having great difficulty either blacklisting > fileinstall or replacing it. > > in etc/org.apache.karaf.features.xml I have tried: > > <blacklistedBundles> > <bundle>mvn:org.apache.felix/org.apache.felix.fileinstall</bundle> > </blacklistedBundles> > > However I can't get this to have any effect. I have traced through with a > debugger, and the LocationPattern.matches method is returning true, and it > appears to be doing the right thing at that level, but the bundle still > starts. I can't see any log messages that might be relevant. > > I also tried using <bundleReplacements> in that file too. I had slight > success -- I can use: > <bundleReplacements> > <bundle > originalUri="mvn:org.apache.felix/org.apache.felix.fileinstall" > > replacement="mvn:org.apache.felix/org.apache.felix.fileinstall/3.6.5-SNAPSHOT"/> > </bundleReplacements> > > and can compile my own version of fileinstall 3.6.5 and I can see that > it's being loaded in. > > I say can. I could. I did that this morning, though I seem unable to > reproduce that now, I'm getting both versions of the bundle now. Anyway, I > struggled to change the group and artifact to something else (wasn't > changing any code, I was just changing the pom to change the maven > coordinates it was building to and then trying to reference that in the > replacement url). But as soon as I did that it went back to loading the > original. > > Anyone got a recipe for providing an alternative implementation of file > install? > > Thanks. >
