Re: [ecf-dev] about capabilities

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

On 10/29/2014 2:06 PM, Cristiano Gavião wrote:

<stuff deleted>

Is that statement still valid for environments with DS?  I could note that exists a component being registered with o.e.e.osgi.services.distribution bundle. DS will trigger the activation of that bundle when registering the topologymanager instance, right?

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.

and what if I have topology implementation, how to filter for one ?

If you have your own topology manager, I would encourage the use of the OSGi topologymanager capability.   Startup is (of course) up to you.

actually I would like to know which and how other components references/binds to a topologymanager service implementation instance. In case I have more than one implementation registered how will those components select the one that I want?

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 [1].    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.

as soon as I learn how to use them properly I will patch one project... ;)

Ok.  My suggestion (for edef examples) is to focus on this example to start:

http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/examples/bundles/com.mycorp.examples.timeservice.consumer.filediscovery

and after this one

http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/examples/bundles/com.mycorp.examples.timeservice.consumer.filediscovery.rest

http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/examples/bundles/com.mycorp.examples.timeservice.consumer.filediscovery.rosgi

Scott