On 21 févr. 2014, at 14:15, Bengt Rodehav <[email protected]> wrote:
> Hello Clement, > > Some comments inline below. > > /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. >> > > Yes, my interceptor sets intercepted to true on the dependency which makes > sure that the filter match. So the filter is not modified by the interceptor, it just add a new property on the chosen service reference to match the filter. > > > >> >>> >>> 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. >> > > Is there anything I can do to investigate this? Is it possible for you to > take a look if there is indeed a "gap" where this can happen? My first guess would be in the ServiceReferenceManager coordinating the interceptors. > > I think that things are a little complicated since I also listen on > configuration changes. I need to recalculate the matching services when the > configuration of the intercepted instance changes. When starting the > container (Karaf), I get more than one configuration change and thus the > dependencies are invalidated more than once. What if the sequence were: > > 1. Configuration change causing the dependencies to become invalidated > 2. Accept. Will set intercepted to true > 3. getServiceReferences which will calculate the required dependencies > 4. Configuration change again causing the dependencies to become invalidated > 5. Accept. Will set intercepted to true > 6. getServiceReferences which will calculate the required dependencies > > Not sure if there is any point in which an instance could become valid when > it shouldn't. > > I will also try to see if the problem could be the configuration admin. I > use file install for my configuration. I have a feeling that the first > configuration being pushed is a default configuration and not the one from > the configuration file. Then that might explain it. > Oh, that’s an interesting hint. That’s definitely possible. Enjoy your vacations, mine are over…. Regards, Clement > >>> >>> 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]
