I don't see a practical problem here. Why is the customizer collecting service properties? It might examine service properties to decide whether to track the service or not. This almost seems like what you want to do is better handled by the proposed addedService customerizer method which would be called after the service is added to the tracker. --
BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Ikuo Yamasaki <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 2009/09/17 01:17 Subject: Re: [osgi-dev] service modification during addingService callback Sent by: [email protected] Hi BJ On Wed, 16 Sep 2009 10:26:40 -0400 BJ Hargrave <[email protected]> wrote: BJ> > However, how about the following case ? BJ> > BJ> > ---- BJ> > 1. The tracked service has been registered already. (ServiceRegistration BJ> > has been returned to the registering bundle1). BJ> > BJ> > 2. Then the tracker gets open. BJ> > BJ> > ==> the addingService() will be called back. in BJ> > BJ> > 3. Asyncronously, bundle1 modifies the properties of the service during BJ> > the callback of addingService(). BJ> BJ> This is a simple race condition. One thread is going to call addingService BJ> as a result of opening the tracker, the other thread is receiving a BJ> ServiceEvent MODIFIED. That's right. BJ> > Even in the case, modifiedService() will NOT be called back. BJ> BJ> Correct. BJ> BJ> > That means, it could happen that a customizer cannot know the fact the BJ> > service property it gets in its addingService() is stale. BJ> BJ> How is it stale? BJ> BJ> If the modification to the service did not result in the service failing BJ> to meet the tracker's filter, then the situation can be understood as if BJ> the modified event happened before the tracker open completed. I'm thinking about this case (it keeps to meet the tracker's filter). First, I would like to remark that what I assume as stale is not ServiceReference but service properties retrieved by ServiceReference#getProperty(key) in addingService(). Even if the service properties are retrieved at the line#10 (which is the last line of addingService()), the service might be modified in the period between line#10 and the ServiceTracker registers the service reference as to be tracked. The customizer cannot know "the service reference has been changed." I mean, the service properties retrieved in addingService() is stale (it is not the latest service properties). Is not a problem from the of view of customizer implementators ? IMO, if service is modified after STARTING the callback of addingService() of the customizer, modifiedService() of the customizer SHOULD be called back AFTER the addingService() has been returned. ======= Ikuo YAMASAKI BJ> If the modification to the service results in the service no longer BJ> meeting the tracker's filter, then one of 2 things will happen. Either the BJ> tracker will detect this and remove the service from consideration before BJ> addingService is called. Or it wil detected this after addingService is BJ> called and will then call removedService to notify the customizer. BJ> BJ> In all cases, the tracker is not tracking a service which does not meet BJ> the tracker's filter. BJ> BJ> > BJ> > This seems not the pathlogical case. BJ> > That would be a problem. BJ> BJ> I don't see any problem. BJ> BJ> -- BJ> BJ> BJ Hargrave BJ> Senior Technical Staff Member, IBM BJ> OSGi Fellow and CTO of the OSGi Alliance BJ> [email protected] BJ> BJ> office: +1 386 848 1781 BJ> mobile: +1 386 848 3788 _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
