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 >
