Hi,
Yes. Makes sense. Thanks for fixing.
Regards
Felix
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
>
