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
