I created the following JIRA: https://issues.apache.org/jira/browse/FELIX-4432
/Bengt 2014-02-21 12:53 GMT+01:00 Clement Escoffier <[email protected]>: > Hi, > > On 20 févr. 2014, at 13:22, Bengt Rodehav <[email protected]> wrote: > > > This is a follow up on another discussion I had with Clement on this > > mailing list: > > > > > http://apache-felix.18485.x6.nabble.com/Using-iPojo-interceptors-tt5006168.html#a5006276 > > > > I'm now trying to get the interceptor solution into production. > > > > Remember that I have to invalidate my instances when their configuration > is > > changed. This is because I need to re-evalutate the dependencies for the > > instance. > > > > Originally, I only called the invalidateSelectedServices() method on the > > DependencyModel. This worked mostly but not when starting a fresh > container > > (I use Karaf and start it with "bin\karaf.bat clean"). My instance then > > first becomes valid but then becomes invalid. I think this is because of > > the ordering. The accept() method had not been called prior to > > the getServiceReferences() method. The dependency is therefore not set to > > "intercepted=true" which makes it invalid. > > the filter is updated by the interceptor. (just want to be sure I > understand). In that case, if the interceptor arrives after the instance > creation, the filter will be set when the interceptor arrives. > > > > > Replacing the call to invalidateSelectedServices() with a call to > > invalidateMatchingServices() seems to do the trick. However, there is one > > small glitch that I would like to fix. > > > > If I have a configuration that should not be valid (e g I specified an > > extender id that is not present) the instance should never be valid. But, > > when starting Karaf (both with "bin\karaf.bat" and "bin\karaf.bat > clean"), > > the instance becomes valid before it becomes invalid. It does end up in > the > > right state (invalid in this case) but for a short period of time it is > > valid which will cause a lot of things to happen in my code that then > must > > be reversed when it becomes invalid. > > > > I logged the sequence of events and it seems that the accept() method is > > called first. I will then set "intercepted=true". This immediately makes > > the instance valid. Shortly thereafter getServiceReferences() is called. > I > > will then re-calculate the dependency requirements and when I later > > invalidate the dependencies the instance will become valid. > > > > So, there is a short time frame where the instance is valid although it > > shouldn't be. How can I fix that? > > This looks like a bug, as the dependency can be valid only if the set of > selected services is not empty. From what you say, it looks like the > dependency is valid because the set of matching services is not empty. > > > > > From my point of view this is similar to a transaction. I do not want the > > instance to become valid before I have done all my "intercepting" which > is > > after BOTH the accept() method AND the getServiceReferences() method have > > been called. > > In theory, it is how it should work... > > > > > BTW I also noted that the "dependencies" member in > > the DefaultDependencyInterceptor class (I extend the > > DefaultServiceRankingInterceptor class) seems to contain duplicates of my > > dependency. The same DependencyModel instance occurs twice in the List. > > Seems like a bug to me. Perhaps the List should be a Set? > > Definitely, could you open an issue ? > > Clement > > > > > /Bengt > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
