Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of heavy@ungoverned.org
 designates 69.89.21.20 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ungoverned.org;
	h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User;
	b=Gf5GjME/l69Bd+tJxrLzdfo2iSy1cfdhwjQpAWFEyOsB3935jItrw07tETwX8lCkZ3usYqyZbe0/jVi/ofOFO9zFx2EHWyhUFE3KIoQBXXoIVzpPBIU2ujJStLmTxh3Y;
Message-ID: <497F4B44.7060006@ungoverned.org>
Date: Tue, 27 Jan 2009 09:58:28 -0800
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: Question on base Felix property handling
References: <497ECFCC.4000605@ascert.com>
In-Reply-To: <497ECFCC.4000605@ascert.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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