Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] trouble creating proxy, when my service interface is in a distinct bundle

Hi David,

David Donohue wrote:
I was able to get things working by moving my service interface code
to a bundle fragment, and registering my ECF client bundle as the host
of that fragment.  For some reason it seems that ECF requires that any
service to be registered must either reside in the same bundle as that
which is creating the ECF client container, or the service must be in
a fragment of that ECF client container bundle.

I would like to investigate this further with you, as this hasn't been my own experience. That is, I've had occasions where the service interface (i.e. IHello interface class) is in a separate bundle from both the bundle that creates the ECF client container, and the bundle that creates the server container, and the client has been able to lookup/find the interface class (to create the proxy) just fine. So I would like to understand these conditions better, and see if I can track down exactly what's going on here. So first some questions:

a) What version of Eclipse/Equinox is being used?
b) What version of ECF/remote services is being used (i.e. the 'new stuff' your workspace...or some previous version of ECF...i.e. which one?) c) What ECF provider are you using (I assume you are using the ECF generic client/server provider, but want to verify). d) Can you describe the case where things *don't* work (i.e. you get the class not found exception) terms of the bundles and classes? e.g. 'bundle A' has the service interface class (and what/if any other classes), 'bundle B' has the service implementation class(es), 'bundle C' has the client application code (and perhaps makes the ECF client container), 'bundle D' has the server...or whatever the bundle/package/class arrangement looks like for your situation. e) If you would prefer and can do this...sending me a zip of the relevant projects would probably be easiest. But if you don't/can't do this then it would be very helpful to look at the code you have to create containers and the code you have to register the remote service (i.e. via the RFC119/remote services registration?...or using ECF registerRemoteService?).

Thanks for your help!  This one took me many hours to figure out, as I
was not getting much help from console debug/error output.  E.g. when
I created the container using this method

containerFactory.createContainer(protocol, new Object[] {serverUri, port});

I got no error message at all; only the ECF connection silently
failed.  Only when I tried using this method:
did I get an error message which directed me to this problem with class loaders.

Hmm. I'm not understanding quite what's going any time you can take on this over next few days David would be most appreciated. BTW, just for everyone's part of the new OSGi 4.2 remote services implementation [1]...which is nearly done BTW...there have been some other simplifications of the ECF container creation process...e.g. more createContainer variants on the IContainerFactory interface (see [2] for the new javadocs of that interface), and as per the discussion on this bug [3], I've added a new extension point to the ECF core that allows container instances to be created *declaratively*/as extensions (in addition to/instead of via java code). So, for example, an extension declared like this will create an ECF generic server container (at the given containerId):


Similarly, markup like this will create a generic client:


The intention behind this is to simplify/streamline the ECF container creation process...i.e. so that people can do it simply by declaring an extension in the plugin.xml OR by using one of the IContainerFactory.createContainer methods (in java code)...or both.

Thanks David. If at all possible, I would like to look at this class loading issue fully, so as to understand what's going on here (especially if you are using the new remote services work described in [1]).



David Donohue

On Sun, Dec 27, 2009 at 9:27 PM, David Donohue <dd@xxxxxxxxxxxxxxxx> wrote:

Usually, this error is because the bundle that contains the interface (i.e. class) is not exporting the package.
Yes I thought of that.  My MANIFEST.MF is in fact exporting the
package in question:

Any other ideas come to mind?  Many thanks,
David Donohue

Back to the top