[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ecf-dev] State of the 119 distribution part
- From: "Rellermeyer Jan Simon" <rellermeyer@xxxxxxxxxxx>
- Date: Mon, 16 Feb 2009 01:26:05 +0100
- Delivered-to: email@example.com
- Thread-index: AcmPxlGGRSFBMl5xTlqSbbPuCyS+kwABO0pw
- Thread-topic: [ecf-dev] State of the 119 distribution part
> I think that the EF admin folks might be doing some work right now
> notices below...one sent this afternoon).
Sigh. Well, I was able to restore my changed from my memory (means head,
not RAM). I have added a new test case. Again, this case works when I do
it from a plain Framework launch config and fails when using JUnit.
Don't know why this happens (timings, race condition?) but I will have a
look tomorrow (UTC).
> Like the OSGi service.id property, there is a remote service id
> (an integer...that is unique within a particular container's set of
> registered services). It's service property 'remote.service.id'...as
> defined in org.eclipse.ecf.remoteservice.Constants.SERVICE_ID.
> But if we still need to add something to the API to accomplish what's
> needed then so be it.
I think we do. It looks like this property is only visible from clients
but not necessarily from server (at least not with my r-osgi provider)
and it's the server that wants to introspect which service (under which
ID) is has just registered. We could make the property visible through
the IRemoteRegistration.getProperty but on the other hand, adding a
method to the registration would allow the provider to define its own
identifiers, combining its own ID with the service ID.