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
