Re: [ecf-dev] about capabilities

[Cristiano Gavião <cvgaviao@xxxxxxxxx>]

2014-10-30 20:48 GMT-02:00 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.

I agree and share your concerns, and that is why I'm looking for knowledge about a BTM and related stuffs of RSA.

Btw, about DS auto-start thing... what I have been used in my environment/system is a selective activation of the DS components/services. I mean, I don't use "immediate" and almost all components have a standard configurationPid and configurationPolicy=ConfigurationPolicy.REQUIRE. This way I have a (some kind) of central bundle that uses ConfigurationAdmin service to create a configuration instance for every desired component. When a configuration is registered DS automatically create and publish an instance of the desired service...

maybe we could use that in ECF too...

I know that there are some environments using the same concept, Karaf, for example uses apache Felix FileInstall bundle to manage such configuration... they have a directory where administrator put properties files that will be used to create the Configuration instance...

 

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?

:( 

I knew that I was missing something here... now it worked... thanks a lot

 

Scott

_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev

--
"Tudo vale a pena se a alma não é pequena..."