On 01/20/2017 04:58 PM, Alexis de Talhouët wrote: > Michael, > > I recall at the time I initially moved netvirt to blueprint, I faced > cyclic dependency. The approach I used is the following: > Instead of having the blueprint resolved the service you need, which end > up having deadlock due to cyclic dependency, resolve the service you > need using WaitingServiceTracker in the class needing the service. So > the blueprint containers will be able to start, and once started, the > service should become available in the OSGi Registry, making them > available to be retrieved by a ServiceTracker.
But that really hides the problem from the activation framework, so it is very much possible for that WaitingServiceTracker never to be resolved (but all bundles to start). I think the correct solution is to decompose the problem down to atomic services, each having its own blueprint container. That way what seems to be a cyclic dependency becomes an acyclic graph -- unless there is truly a cyclic dependency between the classes, in which case they should be fused). Bye, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
