You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by David Jencks <da...@yahoo.com> on 2012/06/16 00:25:16 UTC
[DS] Which comes first, registration or instance creation?
For immediate components exposing a service, currently felix DS trunk first creates the implementation object, then registers it as a service. This is contrary to the spec which explicitly says to first register the service, then create the implementation object.
Note that in any case for delayed components, the service is first registered, and then if anyone requests the service the implementation object is created. So one effect of following the spec is that delayed and immediate components become more similar in that the registration/ instance creation order is the same, and that immediate components get registered as ServiceFactories just like Delayed components.
I'm in favor of following the spec here because I can understand what locking is needed better.
However, this results in a behavior change for a circular dependency situation. See the new CircularReferenceTest.test_A11_B0n_immediate_A_first. Here we have
A > 1.1 > B > 0..n > A and A is activated first.
Currently A is created triggering the creation and activation of B which registers and is available to bind to A. Then A is registered and so B's dependency manager picks it up.
If registration happens before creation per spec, B is registered, sending an event causing A to register. A's registration is followed by activating A. This causes B to activate, and it's dependency manager finds the A registration and tries to get the A service, which isn't ready yet, so it gets null. Then A gets it's B reference and finishes activating.
As the next test shows, if you start B first, B will get an A reference. But if both are delayed rather than immediate, the order doesn't matter, B won't get an A reference unless you disable and re-enable A.
I'd like to get the spec clarified on what should happen with circular references (see https://www.osgi.org/members/bugzilla/show_bug.cgi?id=2410) but think for the order of registration and instance creation we should either follow the spec or get it changed.
Thoughts? Comments?
many thanks
david jencks
Re: [DS] Which comes first, registration or instance creation?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 15.06.2012 um 18:25 schrieb David Jencks:
> For immediate components exposing a service, currently felix DS trunk first creates the implementation object, then registers it as a service. This is contrary to the spec which explicitly says to first register the service, then create the implementation object.
>
> Note that in any case for delayed components, the service is first registered, and then if anyone requests the service the implementation object is created. So one effect of following the spec is that delayed and immediate components become more similar in that the registration/ instance creation order is the same, and that immediate components get registered as ServiceFactories just like Delayed components.
>
> I'm in favor of following the spec here because I can understand what locking is needed better.
+1
You convinced me already ;-)
>
> However, this results in a behavior change for a circular dependency situation. See the new CircularReferenceTest.test_A11_B0n_immediate_A_first. Here we have
>
> A > 1.1 > B > 0..n > A and A is activated first.
>
> Currently A is created triggering the creation and activation of B which registers and is available to bind to A. Then A is registered and so B's dependency manager picks it up.
>
> If registration happens before creation per spec, B is registered, sending an event causing A to register. A's registration is followed by activating A. This causes B to activate, and it's dependency manager finds the A registration and tries to get the A service, which isn't ready yet, so it gets null. Then A gets it's B reference and finishes activating.
The problem here actually is, that not only null is returned but actually an Exception (at least internally in the Felix framework) is thrown due to the circular call into ServiceFactory.
>
> As the next test shows, if you start B first, B will get an A reference. But if both are delayed rather than immediate, the order doesn't matter, B won't get an A reference unless you disable and re-enable A.
>
> I'd like to get the spec clarified on what should happen with circular references (see https://www.osgi.org/members/bugzilla/show_bug.cgi?id=2410) but think for the order of registration and instance creation we should either follow the spec or get it changed.
>
> Thoughts? Comments?
We currently have a number of issues reported with respect to circular dependencies of components/services (FELIX-1824, FELIX-2450, FELIX-2923). I think in general having circular dependencies is a problem and at times even exhibits a design issue.
In any case, we should probably move forward and refactor the service handling along the lines you proposed at the top.
Regards
Felix
>
> many thanks
> david jencks
>