Hi Alexander, I think that the Felix community has always been open to extending OSGi spec-based implementations for use-cases not covered in the spec, as long as it's backward compatible. I don't really have your specific need (yet;) , but if there are others then I think it would make sense to extend the implementation.
Another thing that is worth pointing out is that the TypeConverter class [1] contains a number of public methods that make it really easy to consume and produce Configurator definitions. If the extension you need deviates much from the 'base' Configurator implementation it might be easy enough to create a separate tool which uses the TypeConverter to easily work with the Configurator data. Cheers, David [1] https://github.com/apache/felix-dev/blob/master/cm.json/src/main/java/org/apache/felix/cm/json/impl/TypeConverter.java On Mon, 9 Aug 2021 at 15:49, Alexander Broekhuis <a.broekh...@gmail.com> wrote: > Hi all, > > I'm looking at a way to extend the configurator to read configurations from > more locations. I know the spec does not contain this, but is there some > way to make this possible? > > The use case is that we have a dedicated server which is used to > store/maintain configurations, and these configs are made available to OSGi > components using the ConfigAdmin. However, components can also use the > Configurator to configure itself using a local file or a config from a > bundle. > While those 2 solutions could work next to each other, it gets more > complicated if ranking is necessary. Eg, for the configurator ranking can > be used, which is handled by the configurator itself. However, since > ranking is not something the ConfigAdmin does, this does not take > configurations from the server into account (which would have the highest > ranking in our case). I could, partially, solve this by using start levels. > Eg make the component that reads from the server start after the > configurator. However, if a new bundle is installed, those configurations > are picked up by the configurator again, which might override the config > from the server. > > Now I am looking for a way to extend the Configurator to be able to read > configurations from other sources as well. I know I can clone the > configurator and do this myself, but I'd like to know if there is any > interest in such a feature. Having a clone, which will get outdated/needs > merging, is not something I fancy. > > TiA > > -- > Met vriendelijke groet, > > Alexander Broekhuis >
