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 13:15:19 GMT
Hello Clement,

Some comments inline below.


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

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