[
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
