Re: [ecf-dev] about capabilities

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Cristiano,

On 10/30/2014 1:47 PM, Cristiano Gavião wrote:

Hi Scott,

seems that I wasn't clear, so let me try to explain the first doubt again: about the use of the  Provide-Capability: osgi.remoteserviceadmin.topology; in a environment containing DS running.

You have said:

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.distributi

on 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.

Then I asked if your statement is still valid even when the environment has DS enable. I asked that because I thought that  BasicTopologyManagerComponent activation would trigger its bundle to be activated and call it Activator, even not explicitly starting the o.e.e.osgi.services.distribution bundle.But I could see that is not true.

what do you think about to add a reference for IDistributionConstants inside the BasicTopologyManagerComponent activation ?

I would like to understand what you are looking to get here.  With what you are saying above, I'm thinking that what you are looking for is DS-based full start of the org.eclipse.ecf.osgi.services.distribution bundle (and the start of the BTM).  Is that right?   If it is, I do understand the desire for this, and I have been thinking about how this could be done with the BTM (or some other TM) for my own DS-based OSGi server environments. 

But I do have some concerns about DS-based activation of BTM/distribution that I will share so we can all discuss:   In Eclipse (and perhaps other environments) such auto start could create a potentially dangerous security hole.  What I mean is this:   If the o.e.e.osgi.service.distribution bundle were auto-started by DS in Eclipse, that would mean that upon startup a promiscuous topology manager (like BTM) would be exporting any remote services, but more importantly also *importing* any remote services that were made available to it...e.g. via zeroconf, slp, zookeeper, etc.   Such a promiscuous approach to import could be very dangerous.

Perhaps it's time to consider creating other/additional topology managers (additional to BTM) that are intended for appropriate environments, or having some configuration or system property that allows the existing BTM to be started via DS (e.g. referring to IDistributionConstants in BTMC activate)...or perhaps both are warranted to match different environment use cases.    If this seems like the direction you are interested in, would you please open an enhancement request and we can discuss technical details there?   I'm quite open to adding something to deal with the DS auto start of BTM, but do want to make sure that it does not cause security problems.

about my topology manager question. it is ok, I understood now. I don't have my own now, I'm just investigating how it works and how would ECF play in the use case stated in this spec: https://github.com/osgi/design/raw/master/rfcs/rfc0183/rfc-0183-CloudEcosystems.pdf

I see.   There's not very much to this RFC around topology managers at this point, but if it moves forward there probably will be.

I'm playing with the examples right now. osgi.remoteserviceadmin.topology requirement is ok, but PDE is not resolving osgi.remoteserviceadmin.discovery. I tried the following syntaxes:

Require-Capability: osgi.remoteserviceadmin.discovery; filter:=(&(configs=ecf.generic.client)(version=1.1))

Require-Capability: osgi.remoteserviceadmin.discovery; filter:=(&(configs=ecf.rest.client)(version>=1.1)(!(version>=2.0)))

am I missing something or this is an issue with PDE that is not resolving multi-value attributes as the "configs" ?

I don't think the osgi.remoteserviceadmin.discovery namespace has a 'configs' attribute (as opposed to the osgi.remoteserviceadmin.distribution namespace).   Did you mean to require for the osgi.remoteserviceadmin.distribution namespace?

The discovery namespace does exist, but it has a 'protocols' attribute...e.g.

Provide-Capability: osgi.remoteserviceadmin.discovery;protocols:List<String>="SLP,JSLP,ecf.discovery.jslp,ecf.discovery.jslp.locator,ecf.discovery.jslp.advertiser";version:Version=1.1

So do you mean the osgi.remoteserviceadmin.distribution namespace?

Scott