[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Debugging RFC 119
|
Hi Bryan,
Bryan Hunt wrote:
Scott,
Thank you so much for the quick reply. I set auto_start to true on
the ecf.osgi.* bundles (I own the product, so I get to set
auto_start), and I got the server to work, but not after a bit of
debugging.
When thie following code in DefaultHostContainer is executed:
IContainer[] containers = Activator.getDefault().getContainerManager()
.getAllContainers();
if (containers == null || containers.length == 0)
return null;
containers.length == 0 which causes the function to return null. That
in turn causes:
for (Iterator i = rsContainers.iterator(); i.hasNext();) {
IRemoteServiceContainer rsContainer = (IRemoteServiceContainer) i
.next();
to throw an NPE.
This is a small bug in the DefaultHostContainerFinder class (i.e.
improper handling of null returned from the function causing the NPE).
Yes a new bug would be helpful on this.
The root cause of the problem is the start order of my bundles. The
DS bundle is registering my service and ECF is trying to process the
service before the bundle that constructs the container with:
Activator.getDefault().getContainerManager(1000).getContainerFactory().createContainer("ecf.r_osgi.peer");
is started. Would you consider this a bug? If so, I'll open a bugzilla.
I don't consider the bundle start order issue an ECF bug...as we can't
control or dictate the start order.
Is it possible for you to call the
Activator.getDefault().getContainerManager(1000).getContainerFactory().createContainer("ecf.r_osgi.peer");
before registering your remote service? There are a couple of ways to
do this with DS I believe.
Scott
On May 19, 2009, at 11:34 AM, Scott Lewis wrote:
Hi Bryan,
Bryan Hunt wrote:
I'm trying to get ECF working with R-OSGi / RFC 119 and I'm having
some difficulty. I'm trying to use transparent mode with
declarative services. I've declared my service with the property:
ogsi.remote.interfaces = * and I'm starting my application with:
Activator.getDefault().getContainerManager(1000).getContainerFactory().createContainer("ecf.r_osgi.peer");
My launch configuration includes the following ECF bundles:
org.eclipse.ecf
org.eclipse.ecf.discovery
org.eclipse.ecf.identity
org.eclipse.ecf.osgi.services
org.eclipse.ecf.osgi.services.discovery
org.eclipse.ecf.osgi.services.distribution
org.eclipse.ecf.provider
org.eclipse.ecf.provider.discovery auto_start = true
org.eclipse.ecf.provider.jmdns auto_start = true
org.eclipse.ecf.provider.jslp auto_start = true
org.eclipse.ecf.provider.r_osgi
org.eclipse.ecf.provider.remoteservice
org.eclipse.ecf.provider.sharedobject
When I launch my app, my service gets registered, but there are no
other bundles using that service. I was expecting one of the ecf
bundles or R-OSGi to be using the service.
The problem is likely that that these three bundles:
org.eclipse.ecf.osgi.service
o.e.e.o.services.discovery
o.e.e.o.services.distribution
are never *started*, and so are not 'kicking in' to handle the remote
service registration. There are two solutions to this:
1) explicitly start these bundles (not particularly recommended)
2) Refer to a class in services.distribution (and this will start
distribution and the other two). This could be as simple as referring to
org.eclipse.ecf.osgi.services.distribution.IDistributionConstants
e.g.:
IDistributionConstants.REMOTE_INTERFACES and/or
IDistributionConstants.REMOTE_INTERFACES_WILDCARD
OR
you can use some of the listener/notification interfaces we've
created (that allow listeners to be notified about various parts of
the distribution and discovery)...e.g.
org.eclipse.ecf.osgi.services.distribution.IHostDistributionListener
(for receiving notification about service host events ...e.g. remote
service registration)
org.eclipse.ecf.osgi.services.distribution.IProxyDistributionListener
(for receiving notification about service proxy events...e.g. proxy
creation and registration)
If you setup/use these notification interfaces the bundles will be
started automatically...and the listeners will then allow you to
see/debug what's happening (along with the discovery listeners as
well). The way these listeners are used is via registering a service
that implements these interfaces...e.g.
bundleContext.registerService(IHostDistributionListener.class.getName(),myHostDistributionImpl,null);
Then at remote service registration time (i.e. when you register your
own remote service), the hostDistributionListener will be notified.
This is the service registry 'whiteboard' pattern.
FYI there is test code for the listeners in
org.eclipse.ecf.tests.osgi.services.distribution/org.eclipse.ecf.tests.osgi.services.distribution.AbstractServiceRegisterListenerTest
(and subclasses)
BTW, just as an aside, we (ECF) can't start these bundles in Eclipse
automatically...i.e. as part of Eclipse startup...as explicitly
starting bundles at Eclipse startup is in the domain of the platform
project only.
Am I missing something basic here? Are there any key breakpoints in
ECF I can set to debug the problem?
To start, I would say it's probably better to use the
listeners...because they provide notification of the crucial
host/client events.
If you wish to go further with setting breakpoints, etc then the
following classes provide the basic implementation and you are of
course welcome and encouraged to debug into them.
Service Host:
org.eclipse.ecf.internal.osgi.services.distribution.EventHookImpl
(the service event hook impl, which is responsible for finding
distribution providers/IHostContainerFinder, and then registering the
service remotely on appropriate IContainer instances).
Service Consumer:
org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl
(receives notifications from discovery, and uses discovery meta-data
to lookup/create proxy, and register the proxy service in local
service registry).
BTW, I'm working on documentation and test code as quickly as
possible for all of this (i.e. the RFC119 impl of course, as well as
the listeners, and container finders...which allow one to easily
customize the selection/use of IContainers/remote service provider
impls). If others are able/willing to help with this or contribute
to it, please let me know.
Thanks,
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/ecf-dev
------------------------------------------------------------------------
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
