On 3 mars 2014, at 15:53, Bengt Rodehav <[email protected]> wrote: > OK - I now understand what you mean. It seems that the design is supposed > to do what I expected then. We think alike :-)
Yes… Theoretically it should be like that…. > > I'll add some more tracing as you suggested and then get back to you. > > /Bengt > > > 2014-03-03 15:46 GMT+01:00 Clement Escoffier <[email protected]>: > >> >> On 3 mars 2014, at 15:18, Bengt Rodehav <[email protected]> wrote: >> >>> Hi Clement, >>> >>> Yes, I use the filter to make sure that the instance does not become >> valid >>> until it has been intercepted - that part seems to work. However, in my >>> case, the instance become valid AFTER my accept() method has been called >>> but BEFORE my getServiceReferences() method has been called. This is >>> causing my problems. >>> >>> I'm a little curious regarding your wording: >>> >>> "A (mandatory) dependency becomes valid only if the selected service set >> is >>> not empty. In other words, all your interceptors should have been called >>> before deciding to set the dependency state to valid." >>> >>> I don't see how the first sentence has anything to do with the second >>> sentence. >> >> This is how iPOJO resolves services. It first considers the services from >> the service registry (called base service set). This set is processed by >> tracking interceptor (such as LDAP filter...) to get a matching service set. >> Then, a ranking interceptor is called to sort the set, and to get the >> selected service set. A mandatory service dependency cannot be valid if >> this last set is empty (in theory). That means that both accept and >> getServiceReferences should have been called to determine whether or not >> the dependency is valid. The accept method is called to build the matching >> service set, while getServiceReferences is called to retrieve the selected >> service set. >> >>> >>> I have a dependency declared as follows: >>> >>> @Requires(optional = false, id = "extenders", filter = >>> "(intercepted=true)") >>> private IRouteExtender[] mExtenders; >>> >>> Thus it is mandatory. Also, there are services of type IRouteExtender >>> registered so that part is resolved. But until the accept() method has >> been >>> called the "(intercepted=true)" part is not satisfied. When my accept() >>> method has been called the "(intercepted=true)" part becomes satisfied >> and >>> my instance becomes valid right away instead of waiting for the result of >>> the getServiceReferences() method. This is the problem because in my >>> getServiceReferences() method I evalutate the matching dependencies (by >>> looking at a property) and determine that they are not valid. I therefore >>> return an empty set of matching service references and the instance now >>> becomes invalid. >>> >>> I do not think it should be possible to validate an instance "in the >> midst >>> of intercepting" as is the case for me. I must be completely done >>> intercepting first. >> >> That should not be the case. Definitely a bug.... The dependency state >> should not be re-evaluated before having notified the ranking interceptor. >> >> So far, you are implementing only getServiceReferences, can you implement >> and add traces in onServiceArrival ? >> >> Clement >> >> >> >>> >>> /Bengt >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 2014-03-03 13:51 GMT+01:00 Clement Escoffier < >> [email protected]>: >>> >>>> Hi, >>>> >>>> On 3 mars 2014, at 13:14, Bengt Rodehav <[email protected]> wrote: >>>> >>>>> Hello again Clement! >>>>> >>>>> Skiing trip is now over - time to get back to the interceptors... >>>>> >>>>> Regarding your questions in the last post: Yes, I only add a property >> on >>>>> the chosen service reference (intercepted is set to true), I do not >>>> change >>>>> the filter. >>>>> >>>>> I have tested the theory regarding config admin / file install and it >> is >>>>> not the problem. >>>>> >>>>> It seems to me that there is no guarantee that both accept() and the >>>>> getServiceReferences() are both called before an instance becomes >> valid. >>>> I >>>>> haven't looked at the source code in detail yet but is the design such >>>> that >>>>> this is not supposed to be possible or am I requesting a new feature? >> In >>>>> other words, have I found a bug or not? >>>>> >>>>> Ideally I think it should work as follows: >>>>> >>>>> - When in "interceptor mode" the state of the instance should not >> change >>>>> until all the interceptors (and all callbacks of the interceptors) have >>>>> taken effect. >>>>> >>>>> - Initially then instance should not become valid until all the >>>>> interceptors (and all callbacks of the interceptors) have taken effect. >>>>> >>>>> With "interceptor mode" I mean that something has triggered iPojo to >>>> begin >>>>> calling the registered interceptors. >>>>> >>>>> Not sure if this is in accordance with your design. How is it supposed >> to >>>>> work? >>>> >>>> >>>> It might be a bug and a new feature. >>>> >>>> I designed interceptors to be highly dynamic, so can come and leave at >>>> anytime, and without having the components aware of them. That's why >>>> service dependencies do not know which interceptors handle them. >>>> Unfortunately, this design has some trade-off / drawbacks. If your >> instance >>>> starts before the interceptors, it might be valid for a little amount of >>>> time, until the interceptors handle the dependency. However in your case >>>> you have a filter on the dependency that should avoid this case. >>>> >>>> If you still have this filter, it is definitely a bug. A (mandatory) >>>> dependency becomes valid only if the selected service set is not empty. >> In >>>> other words, all your interceptors should have been called before >> deciding >>>> to set the dependency state to valid. >>>> >>>> About the feature, I start thinking that the independence between the >>>> interceptor and the dependencies may be problematic. For instance, I've >>>> another use case where they implement a new handler (an extension of the >>>> dependency handler) to ensure the availability of one specific >> interceptor. >>>> The dependency is invalid until the interceptor arrives. >>>> >>>> Clement >>>> >>>>> >>>>> /Bengt >>>>> >>>>> >>>>> >>>>> >>>>> 2014-02-24 8:17 GMT+01:00 Clement Escoffier < >> [email protected] >>>>> : >>>>> >>>>>> >>>>>> 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] >>>>>> >>>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
