> However, how about the following case ? > > ---- > 1. The tracked service has been registered already. (ServiceRegistration > has been returned to the registering bundle1). > > 2. Then the tracker gets open. > > ==> the addingService() will be called back. in > > 3. Asyncronously, bundle1 modifies the properties of the service during > the callback of addingService().
This is a simple race condition. One thread is going to call addingService as a result of opening the tracker, the other thread is receiving a ServiceEvent MODIFIED. > > Even in the case, modifiedService() will NOT be called back. Correct. > That means, it could happen that a customizer cannot know the fact the > service property it gets in its addingService() is stale. How is it stale? If the modification to the service did not result in the service failing to meet the tracker's filter, then the situation can be understood as if the modified event happened before the tracker open completed. If the modification to the service results in the service no longer meeting the tracker's filter, then one of 2 things will happen. Either the tracker will detect this and remove the service from consideration before addingService is called. Or it wil detected this after addingService is called and will then call removedService to notify the customizer. In all cases, the tracker is not tracking a service which does not meet the tracker's filter. > > This seems not the pathlogical case. > That would be a problem. I don't see any problem. -- 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
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
