I think this concept is not so common that it would justify the additional complexity to the DS specification to support it.
As you note, you can always disable A in B's activator and enable A in B's deactivator. Alternatively, you could declare A to have an optional, dynamic dependency on B and when B is injected into A, A could then cease providing its function until B is unbound. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Ioannis Canellos <[email protected]> To: [email protected] Date: 2014/01/27 04:55 Subject: [osgi-dev] Declarative Services: Mutually exclusive Components / Component Ranking Sent by: [email protected] Quite often I am coming across the same problem again and again and I was wondering what's the best way to deal with it. The problem is that I have multiple components (say A and B) that are providing similar piece of functionality. At any given time I want only one of the two components to be "active". Something like: if only A is satisfied -> activate A. if only B is satisfied -> activate B. if A and B are satisfied -> activate B if A is activated and later on B gets satisfied -> deactivate A and activate B. If those components are providing a Service I can use service ranking to deal with it. But some times this is not enough and I also need to deactivate the component too. In this case I can do it using the enable()/disable() methods on the component. I am wondering if there are better ways to implement something like "mutually" exclusive components. Would it make sense to introduce the concept of "component ranking" that would allow having multiple components with the same name but only activate the one with the highest ranking? Thanks. -- Ioannis Canellos _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
