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: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer;
  b=NIn/MKwcklYsZ/qV/U6mS38Ua9MMLD4J1pWU8T0w6qgmUTo4l0M3gRhsSOUGFRBMJS9AF1eV0kwLiy/dLP37GRnMUinLIvCS9CYJEqU0qOuKgJ47fjVd3VZywDHhQepCWYbkjOA2ddB8ZvrYB8ClvnxdCEVN3vTrULGox+hNXck=
  ;
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: [DS] [lifecycle methods returning service properties]  How should
 this work?
From: David Jencks <david_jencks@yahoo.com>
In-Reply-To: <890DEFDE-27B5-46A6-93EE-038D853C1471@adobe.com>
Date: Mon, 4 Jun 2012 18:36:25 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E584B90-4F2A-45D5-B350-D4F18C2659AA@yahoo.com>
References: <01B24EA9-413D-4E5D-A48E-3F742688F39D@yahoo.com>
 <890DEFDE-27B5-46A6-93EE-038D853C1471@adobe.com>
To: dev@felix.apache.org


On Jun 4, 2012, at 11:13 AM, Felix Meschberger wrote:

> Hi,
>=20
> Am 04.06.2012 um 19:16 schrieb David Jencks:
>=20
>> cf FELIX-3506, 3377.
>>=20
>> 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:
>>=20
>>       serviceProperties.clear();
>>       for (String key : cc.getServiceReference().getPropertyKeys()) {
>>           serviceProperties.put(key, =
cc.getServiceReference().getProperty(key));
>>       }
>> //now actually add/remove my flag
>>=20
>>=20
>> 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".
>>=20
>> Have I missed an easy way to use the current implementation?
>=20
> Basically the service registration by default are all =
ComponentContext.getProperties() with the exception of the properties =
with a leading dot (considering them private properties).
>=20
> 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.
>=20
> 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

>=20
> Regards
> Felix