|Re: [ecf-dev] DS and zookeeper|
On 4/27/2011 4:07 AM, mike howard wrote:
Although the use cases can be complex, I've found that when you have a plugin that implements BundleActivator (i.e. has an Activator class), that having the plugin activate when one of its classes is loaded is the right thing to do.
Incidently...I've discovered that the lazy start was *not* previously set in the hello example bundle (i.e. org.eclipse.ecf.examples.remoteservices.hello). This may have been the actual cause of the start problem discussed in this thread .
In any event, I've opened a new bug to fix this in the hello example . I will fix this quickly...and in subsequent builds (and ECF releases, of course) I'm hopeful that it will also deal with the problem discussed in . That issue seems to be limited to Equinox 3.6.2 (and does not show itself on 3.7), but in any event...like I said I'm hopeful that it will permanently deal with the issue  on 3.6.2...and I will find the time to test on 3.6.2 to verify.
One resource for this information is the product config:
/org.eclipse.ecf.examples.remoteservices.hello.ds.host/products/Hello Service DS Host (zeroconf,generic).product
i.e. here's the <configuration> for that product:
<plugin id="org.eclipse.ecf" autoStart="true" startLevel="0" />
<plugin id="org.eclipse.ecf.examples.remoteservices.hello.ds.host" autoStart="true" startLevel="0" />
<plugin id="org.eclipse.ecf.osgi.services.distribution" autoStart="true" startLevel="0" />
<plugin id="org.eclipse.ecf.osgi.services.remoteserviceadmin" autoStart="true" startLevel="0" />
<plugin id="org.eclipse.equinox.common" autoStart="true" startLevel="2" />
<plugin id="org.eclipse.equinox.ds" autoStart="true" startLevel="2" />
I recognize that we need to make this information much more available/transparent, however. To do this, I suggest that we
1) Add to the documentation on this wiki page  (or with a link on this page to a new page(s)...with information from the configuration sections of the various product configs. This can/could be considered part of the ECF documentation project , and we can track it there.
2) I would like to create more product configurations...e.g. one for zookeeper,generic for the DS host and consumer (e.g. Hello Service DS Host (zookeeper,generic).product, Hello Service DS Consumer (zookeeper, generic)...it would also be nice to have ones for rosgi as well...e.g. Hello Service DS Host (zookeeper, rosgi).product, Hello Service DS Consumer (zookeeper, rosgi).product. I created an enhancement request for this here . Nice bug number, don't you think? :)
There's an example of doing this with service registration properties (i.e. using DS):
In this file are several service properties...i.e.
<property name="service.exported.interfaces" type="String" value="*"/>
<property name="service.exported.configs" type="String" value="ecf.generic.server"/>
<property name="ecf.exported.containerfactoryargs" type="String" value="ecftcp://localhost:3787/server"/>
The last one (ecf.exported.containerfactoryargs) provides a single argument that specifies the server's ID/URI...including the hostname, the port (3787), and the path (/server).
There are other ways (e.g. programmatically...or using config admin) to configure things for the generic provider (incidently, in case it's not clear, in general every provider has it's own configuration). And we need more documentation on this (i.e. a configuration wiki page for every distribution provider...and for that matter every discovery provider). If anyone can provide some contributions for this as well, please consider helping out/contributing...and coordinate via the ECF documentation project bug .