felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: [DS] [lifecycle methods returning service properties] How should this work?
Date Tue, 05 Jun 2012 11:51:56 GMT

Yes. Makes sense. Thanks for fixing.


Am 05.06.2012 um 03:36 schrieb David Jencks:

> On Jun 4, 2012, at 11:13 AM, Felix Meschberger wrote:
>> Hi,
>> Am 04.06.2012 um 19:16 schrieb David Jencks:
>>> cf FELIX-3506, 3377.
>>> Right now we have it set up so that a lifecycle method can return the exact set
of service properties it wants the service registration to have.  I'm not at all sure this
is a plausible way to operate since usually you'd use this feature to set or unset a flag
in the service properties based on some aspect of the component state.  I could be missing
something, but I don't see an easy way to get the existing set of service properties so you
can modify them with your flag.  I did something like this:
>>>      serviceProperties.clear();
>>>      for (String key : cc.getServiceReference().getPropertyKeys()) {
>>>          serviceProperties.put(key, cc.getServiceReference().getProperty(key));
>>>      }
>>> //now actually add/remove my flag
>>> I think it would be a lot more usable to have the lifecycle methods return a
map of changes, where a null value for a key means "remove the key".
>>> Have I missed an easy way to use the current implementation?
>> Basically the service registration by default are all ComponentContext.getProperties()
with the exception of the properties with a leading dot (considering them private properties).
>> So the idea of returning the complete map is to give the component full and simple
control. And because the properties are fully available in all activator methods (activate,
modify, deactivate) through either the ComponentContext or the configuration Map this is really
straight-forward IMHO.
>> So I would prefer to keep those as is.
> I'm OK with this as long as we strip out the private . properties... see FELIX-3533.
> david jencks
>> Regards
>> Felix

View raw message