felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clement Escoffier <clement.escoff...@gmail.com>
Subject Re: A couple of questions regarding iPojo interceptors
Date Mon, 24 Feb 2014 07:14:46 GMT
Thanks, I will have a look this afternoon.

Clement

On 21 févr. 2014, at 13:14, Bengt Rodehav <bengt@rodehav.com> 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 <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.
>> 
>>> 
>>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message