karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From t..@quarendon.net
Subject Re: Replacing or blacklisting felix fileinstall
Date Fri, 15 Mar 2019 06:09:41 GMT
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

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.

View raw message