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
