[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Debugging RFC 119
|
Scott,
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.
Opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=276982 for 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.
I agree that ECF can't control or dictate the start order, and this is
why I think there's a bug here. ECF is currently dependent on a
bundle constructing the container, and since start order should not be
dictated (being a good OSGi citizen) ECF fails and is thus implicitly
dependent on start order. Since the container is constructed by a
bundle, it seems that ECF should treat the container like a service -
it can come and go at any time since the bundle can come and go at any
time.
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.
I'm not aware of any way to do that other than to try to get DS to
start after the bundle that constructs the container. I've tried
setting the start level of DS to 5 and the bundle that constructs the
container is set to default (4), but DS is still starting way before
the bundle that constructs the container. I'm going to spend a little
time debugging the start order ... any other ideas for a workaround
would be appreciated.
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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
