|Re: [ecf-dev] about capabilities|
On 10/29/2014 2:06 PM, Cristiano Gavião wrote:
I would say that depends upon your impl of the topology manager and how it's setup to work with DS in your environment. But one thing to ask: If you have your own topologymanager impl, why would you also want to start the BasicTopologyManager, which is in o.e.e.osgi.services.distribution bundle? I was expecting that you would want to start your topology manager to *replace* the BTM.
I'm not quite sure what you are asking. Are you asking assuming that more than one TM is running in a single framework?
Typically, there is a single topology manager (although there can be more than one). In the o.e.e.osgi.services.distribution bundle there is a default topology manager implemented by the BasicTopologyMangerImpl/BasicTopologyMangerComponent classes . See the Activator class in the same directory for the non-DS service registration. The reason there are two BTM classes rather than one is so that it can be registered via DS or without DS in non-DS environs).
This BTM's tm policy is 'promiscuous' in that it exports and imports 'everything' that it's notified about. That's why the distribution bundles has this capability policy attribute:
Provide-Capability: osgi.remoteserviceadmin.topology; policy:List<String>="promiscuous"; version:Version=1.1
If you are contemplating having multiple TM's (BTM alongside with your own) rather than replacing the BTM then that's fine, although I admit I don't yet understand the use case for this. If you want to distinguish your own from the BTM via capabilities you could add your private attribute in your Provide-Capability, and/or specify something other than/in addition to "promiscuous" for your tm policy.
But I'm not sure I'm understanding what you are wanting to do wrt the topology manager (replace BTM or both/several).
Sounds like a good idea. Feel free to open an enhancement and contributions are welcome.
Ok. My suggestion (for edef examples) is to focus on this example to start:
and after this one