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
r...@ascert.com
+44 (0)20 7488 3470
www.ascert.com
