felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Rodehav <be...@rodehav.com>
Subject Re: A couple of questions regarding iPojo interceptors
Date Fri, 21 Feb 2014 15:53:37 GMT
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 <bengt@rodehav.com>:

> 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 <bengt@rodehav.com>:
>
> Hello Clement,
>>
>> Some comments inline below.
>>
>> /Bengt
>>
>>
>>
>> 2014-02-21 12:53 GMT+01:00 Clement Escoffier <clement.escoffier@gmail.com
>> >:
>>
>>> Hi,
>>>
>>>
>>> On 20 févr. 2014, at 13:22, Bengt Rodehav <bengt@rodehav.com> 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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message