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