Question on base Felix property handling

[Rob Walker <ro...@ascert.com>]

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). 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.

-- Rob


Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com

Re: Question on base Felix property handling

[Rob Walker <ro...@ascert.com>]

Richard S. Hall wrote:
> Yeah, we did have that, but you are going back quite a few years. :-)
>
Don't make me feel old ! ;)
>
> 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.
>
Actually - that's exactly what we are doing. BUT .... we have a large 
number of legacy bundles that won't get converted immediately, plus we 
use some 3rd party bundles that work from BundleContext.getProperty().

So the model we'd like to create is that both our new property service, 
and old bundles using BundleContext both fall back to the same property 
handler.

I looked at the code - and it seems pretty easy to extend with an extra 
constructor, without breaking anything. The following struck me:

    * the Map pass in the current constructor is copied into a StringMap
      which enforces String keys and case insenstive matches: I'm pretty
      sure all of this behaviour could be preserved in a new/extra
      constructor, in fact the easiest way is that the additional
      constructor take a properties object, since this can only have
      String keys. I did have the following observation while reviewing
      this code
          o I can't find anywhere in  the spec that says BundleContext
            getProperty matches should be case insenstive. I can see a
            number of places where case insensitive matches are noted as
            part of filters, but I can't find an explicit statement that
            his goes to all BundleContext  properties
    * a Immutable view is created for the copied map. Again, this should
      be fine to keep for the new constructor - the view is backed by
      the Map supplied anyhow. Again thiough, I looked in the spec and
      couldn't find an explicit place it's stated that the property Map
      should be immutable. Maybe it's just that framework properties
      must be guaranteed not to change?

I'm happy to do the work and test it - assuming others are ok with it 
that is!

Regards

-- Rob

-- 


Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com

Re: Question on base Felix property handling

["Richard S. Hall" <he...@ungoverned.org>]

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