Rob Walker wrote:
Wondering if there's any reason why we couldn't allow an alternate
Felix constructor that supports a pluggable property handler e.g. a
custom Map or Property class?
I seem to recall in the past we did actually have this (the old
xxxResolver flavour).
Yeah, we did have that, but you are going back quite a few years. :-)
I know with ConfigAdmin and more recent services there are other more
general ways to handle config, but the original
BundleContext.getProperty() is still very useful for the simple cases.
We'd like to tweak our handling so that all our "get some config
property" go back to a common place, including
BundleContext.getProperty(). Allowing a pluggable property handler /
resolver as an optional way to instantiate Felix would give us a handy
way to do this.
Why would this be a feature of the framework as opposed to you
introducing your own configuration service from which your bundles get
their configuration properties? Then you can do whatever you want.
I understand the idea of having to access a service might sound like a
bigger PITA than using BundleContext, but ultimately it is quite similar
to a service interface that gets injected into your bundle too. You
could also centralize access to this service in your bundle somehow so
that you do not need to be accessing services all over your code.
Just a though.
-> richard
