djencks commented on issue #19: URL: https://github.com/apache/felix-dev/pull/19#issuecomment-617384334
Trying to remember the distant past…. I think that the problem this whole thing was designed to solve was that it’s possible to have several references to the same service, even from the same component. (I think this also solves it for multiple components with the same dependency, in the same bundle). If you register several listeners, then you get several events and unfortunate things can happen in between those events. My code was an attempt to get only one event per dependency, no matter how many references that is spread over. IIRC Arnoud’s change change the mapping from “all dependencies on some service”, where DS manages the filters, to “all dependencies with a certain filter on some service”, letting the service registry manage the filters. This introduces some circumstances where multiple events might be needed, but still eliminates the most likely, where for instance you get the service in one place and the service property map in another. I think my idea was to, for instance, with a static reference, get all the references to a particular service updated in between the deactivation and reactivation. With entirely separate events there’s going to be a peculiar short lived state where the two references to the same service/filter will be referring to different instances. David Jencks > On Apr 21, 2020, at 12:42 PM, Thomas Watson <[email protected]> wrote: > > > @tjwatson commented on this pull request. > > In scr/src/main/java/org/apache/felix/scr/impl/BundleComponentActivator.java <https://github.com/apache/felix-dev/pull/19#discussion_r412440777>: > > > if ( listenerInfo != null ) > { > - if ( listenerInfo.remove( filter, listener ) ) > - { > - listenerMap.remove( className ); > - m_context.removeServiceListener( listenerInfo ); > - } > + listenerMap.remove( serviceFilterString ); > Part of me that is concerned about why the code was the way it is currently. I have to admit that I don't know the history of why though. For example, I'm unsure what condition causes the ListenerInfo to even have multiple ExtendedServiceListeners in its list of listeners. There appears to be a one-to-one mapping between a ServiceTracker and a DependencyManager and a DependencyManager manages a single reference and hence a single target filter for the reference. I guess I don't see how multiple targets would come from a single DependencyManager. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub <https://github.com/apache/felix-dev/pull/19#discussion_r412440777>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELDXS67V7O4CMRS4GGWPDRNXZLHANCNFSM4MNG3OYA>. > ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
