Re: Extensions to Configurator

[Alexander Broekhuis <a....@gmail.com>]

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 <cz...@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....@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
> cziegeler@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

-- 
Met vriendelijke groet,

Alexander Broekhuis