Thanks, I will have a look this afternoon. Clement
On 21 févr. 2014, at 13:14, Bengt Rodehav <[email protected]> wrote: > 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
