felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Walker <r...@ascert.com>
Subject Re: Question on base Felix property handling
Date Wed, 28 Jan 2009 06:42:00 GMT

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 

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!


-- Rob


Ascert - Taking systems to the Edge
+44 (0)20 7488 3470

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message