Ah! See, now I can help.
Assuming A & B implement the same service, ranking should be your friend. Just
make the preferred (the cluster) the higher ranking. Clients can use then the
greedy policy to bind to the right one and get switched.
The Standalone one can depend on the Clustered service dynamically. If there is
one, it just forwards all calls to the clustered service
Let A not implement anything. You make it dynamically depend on B. If B is
there, it does nothing. If B is not there, it registers the service
Kind regards,
Peter Kriens
On 29 jan. 2014, at 10:14, Ioannis Canellos <[email protected]> wrote:
> In my case A and B are the standalone and clustered implementation of
> a service. When the "ClusterService" becomes available I want to stop
> the standalone implementation and start the clustered one.
>
> While I am describing the real use case I realise that I could use a
> single component with an optional static reference on the
> "ClusterService". I could then decide if I want to "standalone" or
> "clustered" behaviour by checking if the "ClusterService" is bound or
> not. Using the static policy will guarantee that if the
> "ClusterService" becomes available at a later point my component will
> deactivate/reactivate.
>
> In the most rare case that A was provided by a 3rd part and I was
> implementing B, then I guess I would have to use enable()/disable().
>
> 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
