[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] about capabilities

comments below

2014-10-29 16:33 GMT-02:00 Scott Lewis <slewis@xxxxxxxxxxxxx>:
Hi Cristiano,

On 10/29/2014 9:30 AM, Cristiano GaviÃo wrote:

Hi Scott and all,

I noted that you removed the Provide-Capability from JMS provider here: https://github.com/ECF/JMS/commit/fd16245cc55c2028c77bf6d74430896fd129c95b , but kept in others. what was the reason ?

It was an oversight on my part. ÂI had to remove the existing ones when doing R6 CT tests as they were not well-formed, but forgot to add the correct ones back in. To fix I've created this bug


As you can see by the bug, I've corrected/added and pushed to master. Thanks for the report.

Thanks for that... ;)

I'm looking at the examples and noted that almost all is referencing org.eclipse.ecf.osgi.services.distribution.IDistributionConstants interface. that explicitly makes the bundle to import org.eclipse.ecf.osgi.services.distribution package and consequently the org.eclipse.ecf.osgi.services.distribution bundle installed. ok.

doubt. would I got the same result (ensure that we must have the right ECF bundle installed) using Require-Capability: osgi.remoteserviceadmin.topology instead ?

Not completely (you wouldn't get all the effects). ÂYou would of course have the capability, but you wouldn't also get the starting of the o.e.e.osgi.services.distribution bundle that is triggered by the class load of IDistributionConstants upon app startup (as used by the older examples). The reasons that some of the examples still use IDistributionConstants is 1) that they were written before the RSA topology manager capability existed and haven't been updated; 2) The class dependency on IDistributionConstants simplifies and avoids the need to have an explicit start of the o.e.e.osgi.services.distribution bundle.

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?

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 noted that that are example of the use of the extender for endpoint-descriptions file, but what about to change some example project to demonstrate the other new capabilities stuffs ?

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... ;)


ecf-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

"Tudo vale a pena se a alma nÃo à pequena..."