Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] problems with XMPPContainer and IRemoteServiceContainerAdapter

Hi Scott, 

you are right with my ordering. I just changed my ordering to this:
container = ContainerFactory.getDefault().createContainer(ECFConstants.XMPP);

adapter = (IRemoteServiceContainerAdapter) container

xmppid = new XMPPID(container.getConnectNamespace(), userName + "@"+ server);
IConnectContext connectContext = ConnectContextFactory
.createUsernamePasswordConnectContext(userName, password);
container.connect(xmppid, connectContext);

Now  XMPPContainer container.getAdapter(...) causes an InvocationTargetException


Am 14.10.2010 um 20:00 schrieb Scott Lewis:

Hi Eugen,

This exception is caused by the combination of a) the xmpp provider's limitation of not being able to handle sending a message to 'null'; b) the use of null in XMPP Registry (RegistrySharedObject)...i.e. this line in the stack below

at org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.sendRegistryUpdateRequest(

This is probably caused by the ordering in your code WRT initialization/connecting of the XMPP guess is that your ordering is:

1) Create client container
2) connect the client container
3) call container.getAdapter(IRemoteServiceContainerAdapter.class);
(and this triggers the exception...would be my guess)
4) use the IRemoteServiceContainerAdapter somehow (register or get)

To avoid this exception for the XMPP container the order should be:

1) Create client container
2) call container.getAdapter(IRemoteServiceContainerAdapter.class)
3) connect the container
4) use the adapter

This ordering should prevent this exception for the xmpp container.  This is the ordering in the test code, and it works fine.

The underlying reason for all this startup order complication for the XMPP container is that XMPP has no notion of the *group* that registry updates should be sent to (i.e. the meaning of 'null' for sendRegistryUpdateRequest).    This should perhaps be changed...e.g. to have the 'group' be defined as the (e.g.) active members on your roster...but there isn't a lot of current, active development on the xmpp provider right I haven't been able to dedicate resources to it.

In the short terrm, if you can't change your existing code, it might be possible to modify things for xmpp-based remote services via this class


but I would need to look at it more carefully before saying for sure.


On 10/14/2010 9:12 AM, Eugen Reiswich wrote:
Hi Scott, hi Markus, 

I just realized that the bundle you both mentioned is in the new Git Repo but not in CVS. I just imported from Git: compendium, framework, protocols and providers (btw. is there an easier way to do this e.g. something comparable to projects sets a la releng/org.eclipse.ecf.releng?). 

When I launch my application and try to retrieve a remote service I get the following exception:

[log;+0200 2010.10.14 18:05:48:46;ERROR;org.eclipse.ecf.provider.remoteservice;org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.provider.remoteservice;code=210;message=Exception sending response;severity4; receiver cannot be null for xmpp instant messaging;children=[]]] receiver cannot be null for xmpp instant messaging
at org.eclipse.ecf.internal.provider.xmpp.smack.ECFConnection.sendMessage(
at org.eclipse.ecf.internal.provider.xmpp.smack.ECFConnection.sendAsynch(
at org.eclipse.ecf.provider.generic.ClientSOContainer.queueContainerMessage(
at org.eclipse.ecf.provider.generic.SOContainer.sendMessage(
at org.eclipse.ecf.provider.generic.ClientSOContainer.sendMessage(
at org.eclipse.ecf.provider.generic.SOContainer.sendSharedObjectMessage(
at org.eclipse.ecf.provider.generic.ClientSOContainer.sendSharedObjectMessage(
at org.eclipse.ecf.provider.generic.SOContainer.sendMessage(
at org.eclipse.ecf.provider.generic.ClientSOContainer.sendMessage(
at org.eclipse.ecf.provider.generic.SOContext.sendMessage(
at org.eclipse.ecf.core.sharedobject.BaseSharedObject.sendSharedObjectMsgTo(
at org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.sendRegistryUpdateRequest(
at org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject$1.processEvent(
at org.eclipse.ecf.core.sharedobject.BaseSharedObject.fireEventProcessors(
at org.eclipse.ecf.core.sharedobject.BaseSharedObject.handleEvent(
at org.eclipse.ecf.provider.generic.SOWrapper.svc(
at org.eclipse.ecf.provider.generic.SOWrapper$


Am 14.10.2010 um 17:35 schrieb Scott Lewis:

On 10/14/2010 8:25 AM, Markus Alexander Kuppe wrote:
On 10/14/2010 05:17 PM, Eugen Reiswich wrote:
Hi folks,

I'm trying to use remote services over ECF with the XMPP provider. In
order to register and retriever remote services I need to get the
IPresenceContainerAdapter adapter = (IPresenceContainerAdapter)

I'm running in a NPE. Debugging the ECF-Code I found out that
the XMPPContainer returns null
providing org.eclipse.ecf.remoteservice.IRemoteServiceContainerAdapter as clazz

public Object getAdapter(Class clazz) {
if (clazz.equals(IPresenceContainerAdapter.class))
return this;
if (clazz.equals(ISendFileTransferContainerAdapter.class))
return outgoingFileTransferContainerAdapter;
return super.getAdapter(clazz);

Btw. the IPresenceContainerAdapter works fine. Any idea?
Has the org.eclipse.ecf.provider.xmpp.remoteservice bundle been deployed
and registered?

Just to follow up with an explanation of why this fragment is necessary:  the xmpp.remoteservice bundle re-uses the ECF generic implementation of the does this by creating an IAdapterFactory extension (specifically, XMPPRemoteServiceAdapterFactory).

This extension is then processed and used to respond with non-null IRemoteServiceContainerAdapter in the return super.getAdapter(clazz); in the XMPPContainer impl of getAdapter(Class clazz).

So that fragment is now necessary (along with it's dependency on org.eclipse.ecf.provider.remoteservice) to get/use the IRemoteServiceContainerAdapter for xmpp.


ecf-dev mailing list

ecf-dev mailing list

_______________________________________________ ecf-dev mailing list ecf-dev@xxxxxxxxxxx

ecf-dev mailing list

Back to the top