Hi all, It has been a while since I asked this question. We decided to go for a custom solution, which also supports complex types. I've used the configurator spec as reference, so the resources where helpful.
Thanks! Op ma 9 aug. 2021 om 18:51 schreef Carsten Ziegeler <cziege...@apache.org>: > On that note, this : > > > https://github.com/apache/felix-dev/tree/master/cm.json/src/main/java/org/apache/felix/cm/json > > is actually an API that can be used to read (and write) OSGi > configurations in the format specified by the Configurator. We separated > this out to make it reusable for other use cases. So no need to use > internal classes. > > It should be easy to put a small service on top that reads from anywhere > else like a file system etc. > > Regards > Carsten > > Am 09.08.2021 um 17:35 schrieb David Bosschaert: > > 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 > >> > > > > -- > Carsten Ziegeler > Adobe > cziege...@apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > -- Met vriendelijke groet, Alexander Broekhuis
