Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] org.eclipse.ecf.presence.IFQID

Hi Eugen,

I'll also contact you directly, because I would like to figure out how to work with you on some of the remote mgmt with p2 that I've been doing, but here are some thoughts about what might be going on with this.

So first I need to ask: what is going wrong with the code below? There is the fundamental problem as described here

* XXX: according to _Scott_ _Lewis_ the filterIDs have to be containerIDs
* and not rosterIDs, therefore the IRemoteServiceReferences are not
* properly filtered. Solution needed for this problem! According to
* _Scott_ this might become API in the next release


but I assume from your note that your workaround is not working as expected...is that right?

What are you seeing returned from the query for all services of a given type? (i.e. with a given interface class name)? Is it getting IRemoteServiceReferences from all clients?

Thanks...again lets hook up directly to discuss.

Scott


Eugen Reiswich wrote:
Hi Scott,

the "on demand" access to remote services doesn't work properly for me. There are several problems in retrieving remote services which are described in the method below. If you think this is a worthy issue we can work together on this.

/**
* Returns a list of remote service _proxies_ for a given service name. The given * service might be provided by several users. Use filterIDs and filter to delimit the
* amount of services.
* * @param service
*            The needed remote service name. (Use _yourinterface_.class)
* @param filterIDs
* IRosterEntry-IDs, work as a filter though remote services will be
*            limited to the given user. May be null if the service should
*            be get for all users.
* @param filter
*            Additional filter which checks if the service properties do
*            match the given filter. May be null if all services should be
*            found
* @return A list of remote service _proxies_
* @throws ECFException
* @throws InvalidSyntaxException
*/
public <T> List<T> getRemoteService(Class<T> service, ID[] filterIDs,
String filter) throws ECFException, InvalidSyntaxException {
List<T> remoteServices = new ArrayList<T>();

IRemoteServiceContainerAdapter remoteServiceContainerAdapter = getRemoteServiceContainerAdapter();

/*
* XXX: according to _Scott_ _Lewis_ the filterIDs have to be containerIDs
* and not rosterIDs, therefore the IRemoteServiceReferences are not
* properly filtered. Solution needed for this problem! According to
* _Scott_ this might become API in the next release

* XXX this is a workaround for the above mentioned problem. The idea is
* to get all remote services and ask each serviceReference for the
* containerID. Afterwards the containerID-name will be matched with the
* given rosterID-name in order to filter only those services which are
* requested (filterIDs).
*/

/* 1. get all available services */
IRemoteServiceReference[] refs = remoteServiceContainerAdapter
.getRemoteServiceReferences(null, service.getName(), filter);

Map<String, T> filteredServices = new HashMap<String, T>();

/* 2. filter services for the given rosterIDs */
for (int serviceNumber = 0; serviceNumber < refs.length; serviceNumber++) {

IRemoteService remoteService = remoteServiceContainerAdapter
.getRemoteService(refs[serviceNumber]);
Assert.isNotNull(remoteService);

String containerIDName = refs[serviceNumber].getContainerID()
.getName();
int indexOfContainer = containerIDName.indexOf("@");
String containerUserName = containerIDName.substring(0,
indexOfContainer);

for (ID userID : filterIDs) {
String userIDName = userID.getName();
/*
* XXX workaround for container and _roster_ IDs. Split user names
* and compare only names. This is dangerous as the same user
* can be connected to a XMPP server several times.
* TODO: Compare user resources as well?!?
*/
int indexOfUser = userIDName.indexOf("@");
String userName = userIDName.substring(0, indexOfUser);

if (containerUserName.equals(userName)) {

// get _proxy_ for remote service and add service to the
// service list
T castedService = service.cast(remoteService.getProxy());
Assert.isNotNull(castedService);

/*
* XXX: next workaround. If a user connects and disconnects
* several times user services will also be registered
* several times. Asking for a specific service for a user
* in this method may result in multiple services references. A map
* will avoid multiple services and return only one service
* per user.
*/
filteredServices.put(userIDName, castedService);
break;
}
}

}

remoteServices.addAll(filteredServices.values());
return remoteServices;
}

I hope we can get this fixed as well.

Cheers,
Eugen



Am 02.11.2008 um 21:29 schrieb Scott Lewis:

Hi Eugen,

Eugen Reiswich wrote:
Hi Scott,

obviously I'm not the only one who's working on sunday :) I've tried your new solution with the IFQID and it looks great!!! I will have a deep look at it during the week and check out whether the remote services are working properly with user/resource pairs, but my first impression is that it works pretty good. Thanks Scott!

No problem. Just keep those use cases coming. Also Eugen...I need to hook up with you directly about work I've been doing on remote mgmt...using p2 and ECF remote services. If you are available please let me know directly when we could chat via Skype, etc.



You should not have to specify this property any longer:

props.put(Constants.SERVICE_REGISTRATION_TARGETS, targetIDs);

What is the right way to register remote services, just provide empty Dictionary<?> parameters?

Yes. Now that the 'on-demand' access to IRemoteServices is available (via getRemoteServiceReferences), it should be unnecessary to actually specify service registration targets on the service host as per above.

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



Back to the top