BTW. I will be on skiing vacation for a week so it might take a while before I reply again.
/Bengt 2014-02-21 16:52 GMT+01:00 Bengt Rodehav <[email protected]>: > A correction. I only get this problem when I do "bin\karaf.bat" NOT when I > do a clean start "bin\karaf.bat clean". > > I also did some more logging and the sequence of events seem to be: > > - accept: intercepted > - configurationChanged > - Invalidating mathing... > - accept: intercepted > - Invalidating selected... > - Done invalidating > - Validated > - getServiceReferences > - Invalidated > > Thus, it seems like the instance becomes intermittently valid before the > first call to my interceptor's "getServiceReferences". I guess this is > entirely possible. The intention with requiring the "intercepted=true" on > my dependenies was to make sure that the instance does not become valid > before my interceptor has a chance to intercept it. However, since the > accept() method is called before the getServiceReferences method it still > becomes intermittently valid. > > My dependency look like this: > > @Requires(optional = false, id = "extenders", filter = > "(intercepted=true)") > private IRouteExtender[] mExtenders; > > In this case there are services available that implement the > IRouteExtender interface so when my accept method sets interface=true on > the dependency it immediately becomes resolved. Then when I get to my > "getServiceReferences" method I re-calculate the the dependencies and note > that none of the services implementing the IRouteExtender interfaces is > allowed to match (because they have the wrong service properties) I will > return an empty set of matching services and the instance will become > invalid. > > Not sure how to solve this with interceptors. I would prefer if the > instance could not become valid until both the accept() and the > getServiceReferences() methods were called. Until then my interceptor > hasn't fully been allowed to do its job. > > /Bengt > > Thus > > /Bengt > > > > > > > 2014-02-21 14:15 GMT+01:00 Bengt Rodehav <[email protected]>: > > 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. >> >> >> >>> >>> > >>> > 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? >> >> 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. >> >> >>> > >>> > 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] >>> >>> >> >
