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
