Community
Participate
Working Groups
ECF can/could be the first reference implementation for RFC 119. We should work with the alliance, and RFC authors to create such a reference implementation using the ECF remote services API (and/or modify as necessary). An early draft of RFC 119 is available here http://www.osgi.org/download/osgi-4.2-early-draft.pdf
It's becoming clearer that we (ECF) need to have this work done as quickly as possible so that it is in Galileo. S etting target milestone to 3.0 (Galileo). Jan I would like you to be the lead/assignee for this enhancement request given your presence/participation in OSGi EE. Is this going to work for you (Jan)?
I'll do my very best. I must admit that I increasingly get under pressure because my advisors want me to focus on my research. However, I think I can still find time to get involved in the effort to implement RFC 119.
(In reply to comment #2) > I'll do my very best. I must admit that I increasingly get under pressure > because my advisors want me to focus on my research. However, I think I can > still find time to get involved in the effort to implement RFC 119. > I'm not asking you to do it yourself...rather just work directly with all of us (ECF) and to the extent possible others (e.g. IONA, Siemens, Tim D, etc). Thanks Jan. We'll all attempt to make it worth your while. BTW, could you please put the URL for the most recently available version of RFC 119 here? I have what I think may be an older version. Thanks.
Created attachment 123177 [details] org.eclipse.ecf.osgi.services bundle with org.osgi.services.discovery and org.osgi.services.distribution Proposed new ECF plugin: org.eclipse.ecf.osgi.services. This plugin exports the OSGi EE 4.2 discovery and distribution classes from RFC 119 spec (i.e. packages org.osgi.services.discovery.* and org.osgi.services.distribution.*. The OSGi classes in this bundle are included as per CQs: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2795 https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2959 If this looks ok, I will commit to ECF repo under parallel IP as per 2959.
(In reply to comment #4) > Created an attachment (id=123177) [details] > org.eclipse.ecf.osgi.services bundle with org.osgi.services.discovery and > org.osgi.services.distribution > > Proposed new ECF plugin: org.eclipse.ecf.osgi.services. This plugin exports > the OSGi EE 4.2 discovery and distribution classes from RFC 119 spec (i.e. > packages org.osgi.services.discovery.* and org.osgi.services.distribution.*. > > The OSGi classes in this bundle are included as per CQs: > > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2795 > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2959 > > If this looks ok, I will commit to ECF repo under parallel IP as per 2959. > I've committed this new project to ECF HEAD in /cvsroot/rt/org.eclipse.ecf/framework/bundles/org.eclipse.ecf.osgi.services bundle.
For the information of the people observing this ehancement request. Below is a summary of progress on implementing RFC119. In the notes below, the referenced bundles are to be found in CVS at /cvsroot/rt/org.eclipse.ecf, in the framework/bundles or tests/bundles modules. 1) We've created a new bundle for the OSGI 4.2 DRAFT Compendium code: org.eclipse.ecf.osgi.services. This bundle is modeled after the Equinox project that includes other parts of the compendium codebase...i.e. org.eclipse.osgi.services, and o.e.e.osgi.service *only* includes the RFC119 classes from the OSGi compendium release (see CQ: http://dev.eclipse.org/ipzilla/show_bug.cgi?id=2795). Note that this bundle exposes classes from org.osgi.service.discovery and org.osgi.service.distribution package namespace. 2) We've also created new bundles for the ECF-based impl of the discovery and the distribution parts of RFC119 (i.e. org.eclipse.ecf.osgi.services.discovery and org.eclipse.ecf.osgi.services.distribution respectively). 3) Within org.eclipse.ecf.osgi.services.discovery we now have working implementations of the osgi rfc119 services...ServicePublication handler, Discovery service and DiscoveredServiceTracker. Using the ECF discovery API, this version of service discovery now works with both the ECF jSLP provider and the jmdns/zeroconf provider. 4) We have a test bundle for the discovery implementation at tests/bundles/org.eclipse.ecf.tests.osgi.services.discovery. We've just started adding tests, and everyone is welcome to contribute more/other tests. 5) In the org.eclipse.ecf.osgi.services.distribution we now have working the service publication side of things (i.e. via the RFC119-required osgi.remote.interfaces service property). We have not yet completed the client side, but this should be doable within the next few weeks. When that is complete, we will have a functional implementation of RFC119 that will use *any* ECF remote services provider...and we have the following providers already working: ECF generic, r-OSGI, XMPP, JMS (2), JavaGroups. Hopefully other implementers will take advantage of this, and simply create an ECF remote services provider given their favorite remoting/distribution technology (e.g. axis/soap, Riena, jxta, etc) and then these ECF providers will *automatically* support RFC119...as well as 6) We have a test bundle for the distribution implementation in tests/bundles/org.eclipse.ecf.tests.osgi.services.distribution. Again, this has just started and all contributions to tests are welcome. 7) We've got the following wiki page detailing the work specifically on this enhancement here http://wiki.eclipse.org/ECF/Implementation_of_RFC119 8) We will/are beginning to create examples that use the RFC119 access to discovery and remote services...and would like to work with as much of the community as possible to create a large and diverse set of examples that use RFC119 and Equinox + ECF + providers.
I've added both org.eclipse.ecf.tests.osgi.* bundles to the test feature so they become part of the automated test execution.
I propose the following addition to the ECF core API to support intents: In ContainerTypeDescription: String [] getSupportedIntents(); And in IContainerInstantiator String [] getSupportedIntents(); The addition to IContainerInstantiator will allow providers to expose supported intents at runtime. This is a fairly significant change, as it will mean all existing providers will have to implement getSupportedIntents()...at least in the trivial case...by returning null.
(In reply to comment #8) > I propose the following addition to the ECF core API to support intents: > > In ContainerTypeDescription: > > String [] getSupportedIntents(); > > And in IContainerInstantiator > > String [] getSupportedIntents(); > > The addition to IContainerInstantiator will allow providers to expose supported > intents at runtime. > > This is a fairly significant change, as it will mean all existing providers > will have to implement getSupportedIntents()...at least in the trivial > case...by returning null. > Released this API (in IContainerInstantiator and ContainerTypeDescription) to HEAD.
To begin the client-side implementation of RFC119 distribution, I created two new classes: org.eclipse.ecf.internal.osgi.services.distribution.ECFFindHookImpl - implementation of the RFC126 find hook. org.eclipse.ecf.internal.osgi.services.distribution.ECFDiscoveredServiceTracker - implementation of RFC119 DiscoveredServiceTracker for responding asynchronously to services discovered by the discovery implementation. The find hook is used for handling client-side queries for remote services (e.g. through bundleContext.getServiceReference(...)...with osgi.remote.interfaces. The DiscoveredServiceTracker implementation is intended to be used to respond asynchronous discovery notifications (e.g. by doing proxy creation and registration). Jan and Markus...which of these would you prefer I work on over the coming days? My inclination is to work on the find hook implementation, but if this is something you wish to do/can do, then I'll work on the dst implementation.
Created attachment 126410 [details] proposed IRemoteServiceID and additions to IRemoteServiceRegistration, IRemoteServiceReference and IRemoteServiceContainerAdapter In the mailing list thread here http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg02089.html we discuss the possibility of adding to the ECF remote services API an identifier for remote service registrations (i.e. IRemoteServiceRegistration). Here's the dialog from the thread: >> Like the OSGi service.id property, there is a remote service id >> property >> (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. I propose that we 1) Create a new interface (in org.eclipse.ecf.remoteservice) IRemoteServiceID that extends ID and declares methods: ID getContainerID(); int getContainerRelativeID(); 2) Add method to IRemoteServiceRegistration IRemoteServiceID getID(); 3) Add method to IRemoteServiceReference IRemoteServiceID getID(); 4) NEW: I propose that we *also* add methods on IRemoteServiceContainerAdapter: IRemoteServiceReference getRemoteServiceReference(IRemoteServiceID serviceID); IRemoteServiceID createRemoteServiceID(ID containerID, int containerRelative) throws IDCreateException; The intention behind these methods is that *clients* that have/can create an IRemoteServiceReferenceID can then easily lookup IRemoteServiceReferences (and IRemoteServices via IRemoteService getRemoteService(IRemoteServiceReference)). So, for example, I'm working on the OSGI RFC 119 client impl based upon the ECF remote service provider, and this will facilitate creating unique proxies for remote services when the discovery implementation notifies the DiscoveredServiceTrackerImpl that a new remote service has been discovered. Essentially the handler in the DiscoveredServiceTrackerImpl will create an IRemoteServiceID (from the discovered service properties), use it to get the associated IRemoteServiceReference (and IRemoteServiceContainerAdapter), get an IRemoteService and call IRemoteService.getProxy() to get/create a proxy to register as a local service in the local service registry. All this is possible/doable without an IRemoteServiceID, but the IRemoteServiceID will make it much easier to accomplish consistently across providers.
(In reply to comment #11) <stuff deleted> > I propose that we > > 1) Create a new interface (in org.eclipse.ecf.remoteservice) IRemoteServiceID <stuff deleted> I've committed a version of this new API to HEAD...for both the API changes/additions (org.eclipse.ecf.remoteservices), as well as org.eclipse.ecf.provider.remoteservice and an implementation for org.eclipse.ecf.provider.r_osgi. Jan and/or Markus...please examine the r_OSGI provider for correctness...as I've added IRemoteServiceID in number of places.
More progress to report. I've somewhat restructured, simplified, and documented the EventHookImpl for handling remote service registrations (a server for a remote service). Just for my and other's understanding, I wanted to go through the sequence of a server registering a remote service and a client discovering and accessing the remote service. 1) Service that has a service to be accessed remotely published calls: bundleContext.registerService(interface,service,properties); where properties includes osgi.remote.interfaces = collection of strings, or wildcard (e.g. '*') and optionally several other osgi service properties (see ServiceConstants.*), and optionally an ECF remote services container ID (with service property name org.eclipse.ecf.remoteservice.Constants.SERVICE_CONTAINER_ID). 2) With the ECF service registry hook implementation (in org.eclipse.ecf.internal.osgi.services.distribution.EventHookImpl and org.eclipse.ecf.internal.osgi.services.distribution.AbstractEventHookImpl) the registration (and unregistration) responds to 1, and a) registers the service with the ECF remote service container adapter(s) (via IRemoteServiceContainerAdapter.registerRemoteService). b) creates a ServicePublication service (for OSGi RFC 119 discovery), and puts that in the service registry (whiteboard pattern). This much is working just fine in my tests. I'm working on/creating more tests in addition to the ones that Jan created last week. 3) The OSGi discovery is then to respond to ServicePublication registrations (see impl in org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler). The ServicePublicationHandler responds to ServicePublication registrations, by using the ECF discovery API to publish the data in the service publication handler to both zeroconf and jslp (via the CompositeDiscoveryContainer), using a certain service type. This much is working, but I need to add more tests to verify that all the necessary service properties are published, to both zeroconf and jslp. 4) On the client side, the ECF discovery api calls a service listener (set up in the ServicePublicationHandler) to notify it that a new service is discovered. If the service type matches, then the handler finds all matching DiscoveredServiceTrackers (i.e. all DiscoveredServiceTracker instances in service registry), and calls DiscoveredServiceTracker.serviceChanged(DiscoveredServiceNotification). I am in the middle of testing this, to verify that registered discovered service trackers are notified. 5) In the ECF distribution implementation, I'm working on the DiscoveredServiceNotification implementation (class: org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl). That is intended to respond to ECF discovery notifications. This class is not yet complete, but I'm working on it today/tonight/tomorrow. Once complete (or at least complete enough to test), I will register this DiscoveredServiceTracker in the distribution activator. The job of this DiscoveredServiceNotification instance is to respond to notifications by a) getting the metadata about ECF remote services out of the discovery service properties b) use that metadata to retrieve/get a set of client-side IRemoteServiceContainerAdapter instances. c) use the metadata to call rsca.getRemoteServiceReferences(...), create IRemoteServices with those, and create a proxy (using IRemoteService.getProxy()). d) use the proxy from c to register a *local* instance of the service in the client's service registry, and thereby allow clients to transparently get (e.g. via service tracker) and then use (via proxy.<whatever>) the remote service via the proxy. Once 5 is in place and tested, we should be able to demonstrate RFC 119 distribution and discovery that are implemented using the abstract ECF remote services and discovery APIs...which will then automatically support all providers (i.e. discovery=zeroconf and jslp, distribution=ecf generic, r-osgi, jms, javagroups, xmpp, skype.
I'm testing step 3 of comment #13, by registering a remote service via the new test: org.eclipse.ecf.tests.osgi.services.distribution.GenericRemoteServiceRegisterTest. All is going well when I 'turn off' the jslp provider and manually start the jmdns provider. When I do that, I receive this trace output (from ServicePublicationHandler in o.e.e.osgi.services.discovery bundle) (TRACE)[02/23/09;19:53:33:480]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#publishService(publishing serviceReference={org.osgi.service.discovery.ServicePublication}={rsvc.cfn=ecf.generic.client, rsvc.ns=ecf.namespace.generic.remoteservice, service.properties={}, service.interface=[org.eclipse.ecf.tests.remoteservice.IConcatService], osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.GUID:6Sg40FyTWAq7WJ7ofYQS3CNQ3fc=, service.id=114}, svcInfo=ServiceInfo[uri=osgiservices:unknown;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._IANA];name=service.114;full=_osgiservices._tcp.local._IANA@service.114];priority=-1;weight=-1;props=ServiceProperties[{rsvc.cfn=ecf.generic.client, rsvc.ns=ecf.namespace.generic.remoteservice, service.interface=org.eclipse.ecf.tests.remoteservice.IConcatService, osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.GUID:6Sg40FyTWAq7WJ7ofYQS3CNQ3fc=}]]) (TRACE)[02/23/09;19:53:37:590]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#handleOSGIServiceDiscovered(serviceInfo=ServiceInfo[uri=osgiservices://192.168.1.101:65535;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._IANA];name=service.114;full=_osgiservices._tcp.local._IANA@service.114];priority=0;weight=0;props=ServiceProperties[{rsvc.cfn=ecf.generic.client, rsvc.ns=ecf.namespace.generic.remoteservice, service.interface=org.eclipse.ecf.tests.remoteservice.IConcatService, osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.GUID:6Sg40FyTWAq7WJ7ofYQS3CNQ3fc=}]]) (TRACE)[02/23/09;19:53:38:605]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#publishService(publishing serviceReference={org.osgi.service.discovery.ServicePublication}={rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.properties={}, service.interface=[org.eclipse.ecf.tests.remoteservice.IConcatService], osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server, service.id=115}, svcInfo=ServiceInfo[uri=osgiservices:unknown;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._IANA];name=service.115;full=_osgiservices._tcp.local._IANA@service.115];priority=-1;weight=-1;props=ServiceProperties[{rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.interface=org.eclipse.ecf.tests.remoteservice.IConcatService, osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server}]]) (TRACE)[02/23/09;19:53:49:511]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#publishService(publishing serviceReference={org.osgi.service.discovery.ServicePublication}={rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.properties={}, service.interface=[org.eclipse.ecf.tests.remoteservice.IConcatService], osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server, service.id=117}, svcInfo=ServiceInfo[uri=osgiservices:unknown;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._IANA];name=service.117;full=_osgiservices._tcp.local._IANA@service.117];priority=-1;weight=-1;props=ServiceProperties[{rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.interface=org.eclipse.ecf.tests.remoteservice.IConcatService, osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server}]]) (TRACE)[02/23/09;19:53:51:104]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#handleOSGIServiceUndiscovered(serviceInfo=ServiceInfo[uri=unknown://192.168.1.101;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._iana];name=service.114;full=_osgiservices._tcp.local._iana@service.114];priority=-1;weight=-1;props=ServiceProperties[{}]]) (TRACE)[02/23/09;19:53:51:120]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#handleOSGIServiceUndiscovered(serviceInfo=ServiceInfo[uri=unknown://192.168.1.101;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._iana];name=service.115;full=_osgiservices._tcp.local._iana@service.115];priority=-1;weight=-1;props=ServiceProperties[{}]]) (TRACE)[02/23/09;19:53:51:276]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#handleOSGIServiceDiscovered(serviceInfo=ServiceInfo[uri=osgiservices://192.168.1.101:65535;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._IANA];name=service.117;full=_osgiservices._tcp.local._IANA@service.117];priority=0;weight=0;props=ServiceProperties[{rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.interface=org.eclipse.ecf.tests.remoteservice.IConcatService, osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server}]]) (TRACE)[02/23/09;19:53:55:307]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#handleOSGIServiceUndiscovered(serviceInfo=ServiceInfo[uri=unknown://192.168.1.101;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._iana];name=service.117;full=_osgiservices._tcp.local._iana@service.117];priority=-1;weight=-1;props=ServiceProperties[{}]]) (TRACE)[02/23/09;19:53:58:541]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#publishService(publishing serviceReference={org.osgi.service.discovery.ServicePublication}={rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.properties={}, service.interface=[org.eclipse.ecf.tests.remoteservice.IConcatService], osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server, service.id=119}, svcInfo=ServiceInfo[uri=osgiservices:unknown;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._IANA];name=service.119;full=_osgiservices._tcp.local._IANA@service.119];priority=-1;weight=-1;props=ServiceProperties[{rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.interface=org.eclipse.ecf.tests.remoteservice.IConcatService, osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server}]]) (TRACE)[02/23/09;19:54:00:213]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#handleOSGIServiceDiscovered(serviceInfo=ServiceInfo[uri=osgiservices://192.168.1.101:65535;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._IANA];name=service.119;full=_osgiservices._tcp.local._IANA@service.119];priority=0;weight=0;props=ServiceProperties[{rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.interface=org.eclipse.ecf.tests.remoteservice.IConcatService, osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server}]]) (TRACE)[02/23/09;19:54:04:244]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#handleOSGIServiceUndiscovered(serviceInfo=ServiceInfo[uri=unknown://192.168.1.101;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._iana];name=service.119;full=_osgiservices._tcp.local._iana@service.119];priority=-1;weight=-1;props=ServiceProperties[{}]]) This all looks good, as multiple service publications are published and then unpublished...and you can see that handleOSGIServiceDiscovered and handleOSGIServiceUndiscovered are called (these are within the IServiceListener). But when I set the jslp plugin to run normally (i.e. within junit plugin test, including all workspace and enabled plugins), I get the following output: (TRACE)[02/23/09;20:07:46:163]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#publishService(publishing serviceReference={org.osgi.service.discovery.ServicePublication}={rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.properties={}, service.interface=[org.eclipse.ecf.tests.remoteservice.IConcatService], osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server, service.id=121}, svcInfo=ServiceInfo[uri=osgiservices:unknown;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._IANA];name=service.121;full=_osgiservices._tcp.local._iana@service.121];priority=-1;weight=-1;props=ServiceProperties[{rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.interface=org.eclipse.ecf.tests.remoteservice.IConcatService, osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server}]]) (TRACE)[02/23/09;20:07:47:335]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#publishService(publishing serviceReference={org.osgi.service.discovery.ServicePublication}={rsvc.cfn=ecf.generic.client, rsvc.ns=ecf.namespace.generic.remoteservice, service.properties={}, service.interface=[org.eclipse.ecf.tests.remoteservice.IConcatService], osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.GUID:jtaLtdemeXOPDxpwncixoMlpGpI=, service.id=122}, svcInfo=ServiceInfo[uri=osgiservices:unknown;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._IANA];name=service.122;full=_osgiservices._tcp.local._iana@service.122];priority=-1;weight=-1;props=ServiceProperties[{rsvc.cfn=ecf.generic.client, rsvc.ns=ecf.namespace.generic.remoteservice, service.interface=org.eclipse.ecf.tests.remoteservice.IConcatService, osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.GUID:jtaLtdemeXOPDxpwncixoMlpGpI=}]]) Exception in Multicast Receiver Threadextra data found .remoteservice.IConcatService),(osgi.remote.endpoint.id=org. ^ Exception during sending of SRVREG - xid=14964, locale=en_US, url: service:osgiservices://osgiservices://null, serviceType: service:osgiservices, scopeList: [local], attList: [(rsvc.cfn=ecf.generic.client), (x-28392-SERVICEIDNAME=service.122), (rsvc.ns=ecf.namespace.generic.remoteservice), (service.interface=org.eclipse.ecf.tests.remoteservice.IConcatService), (osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.GUID:jtaLtdemeXOPDxpwncixoMlpGpI=)] to TILAPIA/192.168.1.101:427 Exception:Receive timed out (TRACE)[02/23/09;20:07:52:382]CAUGHT Receive timed out (org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#publishService) org.eclipse.ecf.core.util.ECFRuntimeException: Receive timed out at org.eclipse.ecf.provider.jslp.container.JSLPDiscoveryContainer.registerService(JSLPDiscoveryContainer.java:191) at org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler.publishService(ServicePublicationHandler.java:325) at org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler.addServicePublication(ServicePublicationHandler.java:178) at org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler.addingService(ServicePublicationHandler.java:132) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:881) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:233) at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:825) at org.eclipse.osgi.internal.serviceregistry.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:121) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:944) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:219) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:151) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:763) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:718) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:129) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:206) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:532) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:550) at org.eclipse.ecf.internal.osgi.services.distribution.EventHookImpl.publishRemoteService(EventHookImpl.java:134) at org.eclipse.ecf.internal.osgi.services.distribution.EventHookImpl.registerRemoteService(EventHookImpl.java:97) at org.eclipse.ecf.internal.osgi.services.distribution.AbstractEventHookImpl.handleRegisteredServiceEvent(AbstractEventHookImpl.java:114) at org.eclipse.ecf.internal.osgi.services.distribution.AbstractEventHookImpl.event(AbstractEventHookImpl.java:53) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyEventHooksPrivileged(ServiceRegistry.java:1122) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEventPrivileged(ServiceRegistry.java:750) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.publishServiceEvent(ServiceRegistry.java:718) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.register(ServiceRegistrationImpl.java:129) at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.registerService(ServiceRegistry.java:206) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:532) at org.eclipse.ecf.tests.osgi.services.distribution.AbstractDistributionTest.registerService(AbstractDistributionTest.java:159) at org.eclipse.ecf.tests.osgi.services.distribution.AbstractDistributionTest.registerDefaultService(AbstractDistributionTest.java:169) at org.eclipse.ecf.tests.osgi.services.distribution.GenericRemoteServiceRegisterTest.testRegisterAllContainers(GenericRemoteServiceRegisterTest.java:55) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:574) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:556) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:511) at org.eclipse.equinox.launcher.Main.run(Main.java:1270) at org.eclipse.equinox.launcher.Main.main(Main.java:1246) (TRACE)[02/23/09;20:07:56:663]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#publishService(publishing serviceReference={org.osgi.service.discovery.ServicePublication}={rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.properties={}, service.interface=[org.eclipse.ecf.tests.remoteservice.IConcatService], osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server, service.id=124}, svcInfo=ServiceInfo[uri=osgiservices:unknown;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._IANA];name=service.124;full=_osgiservices._tcp.local._iana@service.124];priority=-1;weight=-1;props=ServiceProperties[{rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.interface=org.eclipse.ecf.tests.remoteservice.IConcatService, osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server}]]) (TRACE)[02/23/09;20:08:01:990]TRACING org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler#publishService(publishing serviceReference={org.osgi.service.discovery.ServicePublication}={rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.properties={}, service.interface=[org.eclipse.ecf.tests.remoteservice.IConcatService], osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server, service.id=126}, svcInfo=ServiceInfo[uri=osgiservices:unknown;id=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.local._IANA];name=service.126;full=_osgiservices._tcp.local._iana@service.126];priority=-1;weight=-1;props=ServiceProperties[{rsvc.cfn=ecf.generic.server, rsvc.ns=ecf.namespace.generic.remoteservice, service.interface=org.eclipse.ecf.tests.remoteservice.IConcatService, osgi.remote.endpoint.id=org.eclipse.ecf.core.identity.StringID:ecftcp://localhost:30000/server}]]) I happen to be running a recent version of ECF (and jslp and zeroconf, etc) within the Eclipse instance that initiates the tests...is this because there is some issue with running two SLP instances on the same process? Also, I've noticed that the zeroconf services don't currently (today's build) appear in the discovery view...is this expected? Do I have to do something special to use the CompositeContainer (and get both)? Please let me know if you understand and/all of the above.
This part looks interesting: Exception in Multicast Receiver Thread extra data found .remoteservice.IConcatService),(osgi.remote.endpoint.id=org. ^ The attributes passed to jSLP don't comply with ABNF defined for SLP [1]. At least the (generated) attribute parser doesn't like it. [1] /ch.ethz.iks.slp/src/main/java/ch/ethz/iks/slp/impl/attr/attributes.abnf Exception during sending of SRVREG - xid=14964, locale=en_US, url: service:osgiservices://osgiservices://null, serviceType: service:osgiservices, scopeList: [local], attList: [(rsvc.cfn=ecf.generic.client), This might be bug #258252. Btw. why did you clone most discovery constants in org.eclipse.ecf.osgi.services.discovery.ECFServicePublication? org.eclipse.ecf.discovery.identity.IServiceTypeID and org.eclipse.ecf.discovery.ServiceInfo don't work for rfc119?
(In reply to comment #15) > This part looks interesting: > > Exception in Multicast Receiver Thread > extra data found > .remoteservice.IConcatService),(osgi.remote.endpoint.id=org. > ^ > The attributes passed to jSLP don't comply with ABNF defined for SLP [1]. At > least the (generated) attribute parser doesn't like it. > > [1] /ch.ethz.iks.slp/src/main/java/ch/ethz/iks/slp/impl/attr/attributes.abnf > > Exception during sending of SRVREG - xid=14964, locale=en_US, url: > service:osgiservices://osgiservices://null, serviceType: service:osgiservices, > scopeList: [local], attList: [(rsvc.cfn=ecf.generic.client), > > This might be bug #258252. ok. Looks like 258252 might be easily fixed. That would be great. > > > Btw. why did you clone most discovery constants in > org.eclipse.ecf.osgi.services.discovery.ECFServicePublication? > org.eclipse.ecf.discovery.identity.IServiceTypeID and > org.eclipse.ecf.discovery.ServiceInfo don't work for rfc119? > Maybe it was done in a fit of despair :). I'll remove them. One other question: I've notice two things about discovery/discovery ui... 1) In Eclipse, I don't seem to discover/show iTunes and other zeroconf services any more 2) I thought CompositeContainer was used (and front ended jslp and zeroconf), but in debugging the test case (run with all plugins going) I noticed that it's the jslp container that's returned from the discovery service tracker. Is there something wrong with this, or is it as intended? Thanks.
Created attachment 126703 [details] Implementation of the RFC0119 Discovery Service by SEN As discussed in our F2F-Meeting with the ECF-Coreteam in Munich on February 11th., 2009 Siemens Enterprise Communications (SEN) would like to contribute an implementation of the RFC0119 Discovery Service to the ECF project. Please be aware, that this is a snapshot of the RFC0119 Discovery Service, as currently defined within the OSGi-EEG. - However it has not yet been officially released by the OSGi Alliance. The goal from our side would be work together to integrate this OSGi service with the available ECF Discovery as well as to help that a working RFC0119 DSW & Discovery Service is available in time for the Eclipse 'Galileo' release. Please also note, that this snapshot does not contain the test-suite available on our side. - From our POV the way how to proceed with that should be tackled in a later step, when the CQ process, etc. has progressed. Should changes arise from an OSGi Standardization POV, the plan of SEN would be to update this snapshot as needed to support the integration into ECF. Looking forward talking to the complete team at the next scheduled conf.-call. With best regards, Viktor Ransmayr Siemens Enterprise Communications GmbH & Co. KG SEN PRO CTO SE Hofmannstr. 51 80200 Muenchen, Germany Tel.: +49-89-722-34076 Mobil: +49-151-1216-5853 viktor.ransmayr@siemens.com Communication for the open minded www.siemens.com/open Siemens Enterprise Communications GmbH & Co. KG; Registered office: Munich; Commercial registry: Munich, HRA 88546; WEEE-Reg.Nr. DE 27980375; General Partner: Siemens Enterprise Communications Management GmbH; Managing Directors: James R. O誰eill, Stephen Jones, Todd Schorr; Registered office: Munich; Commercial registry: Munich, HRB 163415 Siemens Enterprise Communications GmbH & Co. KG is a Trademark Licensee of Siemens AG Important notice: This e-mail and any attachment thereof contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank you.
Comment on attachment 126410 [details] proposed IRemoteServiceID and additions to IRemoteServiceRegistration, IRemoteServiceReference and IRemoteServiceContainerAdapter obsolete
Status Report for RFC 119 implmentation: 1) Discovery. The ECF discovery API-based implementation is in place and working with both the jmdns (zeroconf) and jslp (slp)-based providers. ServicePublication instances added to the service registry will be published via ECF discovery provider(s). The DiscoveredServiceTracker matching is not yet implemented, but is a relatively minor part of the discovery specification. 2) Distribution. The ECF remote services API-based implementation is now in place and working with the ECF generic and r-OSGi providers. The org.eclipse.ecf.osgi.services.distribution bundle includes a service registry hook that intercepts BundleContext.registerService calls with the specified properties and directs them to ECF remote services containers. 3) Testing. I've reorganized the test cases in org.eclipse.ecf.tests.osgi.services.discovery and org.eclipse.ecf.tests.osgi.services.distribution. The intention is to provide a set of abstract classes that can be extended in order to test the proper functioning for discovery providers and remote service providers. For example, there are now subclasses for the ecf generic remote service provider and r-OSGi remote service provider. Remaining Items a) DiscoveredServiceTracker matching (described in 1 above) b) discovery bug #266723 c) additional abstract test cases d) multi-process testing and test harness (see here http://www.theserverlabs.com/blog/2008/11/24/distributed-junit-testing-with-gridgain/ for a possible test infrastructure e) additional provider tests (e.g. XMPP, JMS, Skype).
With the recent split of IDCA into idiscoveryAdvertiser and locator, it should be fairly easy to extend discovery tests to multi VM tests. We just need to make the IDA remotely available on the locator end via 119. So basically we are just missing the deployment of the second runtime. This is something that initially could be done with an ant task that copies to the remote side and spans the java process. The 119 in this scenario needs to come from static files.
Status report on this implementation effort. 1) We now have a working implementation of both the RFC 119 discovery and distribution...based upon the ECF discovery API and remote services APIs respectively. 2) I've updated the osgi 4.2 compendium classes to version 20090305, which seems to have the latest changes to RFC 119 classes (i.e. small changes to DistributionProvider interface mostly). I've updated our own DistributionProviderImpl accordingly, and updated test cases. 3) The three bundles that implement RFC 119 based upon ECF discovery and remote services are: org.eclipse.ecf.osgi.services: Classes from 4.3 compendium as per CQ: http://dev.eclipse.org/ipzilla/show_bug.cgi?id=2795 org.eclipse.ecf.osgi.services.discovery: Impl of RFC 119 discovery...via ECF discovery API. The DiscoveredServiceTracker matching is not yet implemented. org.eclipse.ecf.osgi.services.distribution: Impl of RFC 119 distribution via ECF remote services API. The DistributionProvider.getExposedProperties is not yet implemented. Each of these three bundles is CVS at /cvsroot/rt/org.eclipse.ecf module: compendium/bundles 4) There are now test cases in the following tests bundles: a) org.eclipse.ecf.tests.osgi.services.discovery b) org.eclipse.ecf.tests.osgi.services.distribution I'm currently adding to the distribution tests (and the abstract classes that support them), so that we and others can use to test alternative providers as well as test the RFC 119 impls directly. Without objection, I'm soon going to mark this bug as fixed, and we'll file individual other bugs as needed to finish impls, fix bugs as found, identify and fix bugs in providers, make other enhancements (like file-based discovery bug #267390, etc.)
(In reply to comment #21) > Status report on this implementation effort. > <stuff deleted> New status: r-OSGi provider now working as RFC 119 provider. See OSGiServiceRegisterTest and GenericServiceRegisterTest in org.eclipse.ecf.tests.osgi.services.distribution.
Created attachment 128704 [details] discovery patch Refactorings for org.eclipse.ecf.osgi.services.discovery. - Removed org.eclipse.ecf.osgi.services.distribution -> org.eclipse.ecf.discovery dependency -- Distribution uses ServiceEndpointDescription to determine endpoint identity (instead of IServiceID). Internally ECF's SED still delegates identity to IServiceID -- ServiceEndpointDescriptionImpl has been renamed to ECFServiceEndpointDescription and turned into an abstract superclass -- ECFServiceEndpointDescriptionImpl has been moved to the internal package - General code cleanup My use case is SEN's newly contributed file based discovery provider. It does not implement ECF discovery (yet?). Btw. thanks Thomas.
Created attachment 128705 [details] mylyn/context/zip
(In reply to comment #23) > Created an attachment (id=128704) [details] > discovery patch > > Refactorings for org.eclipse.ecf.osgi.services.discovery. > > - Removed org.eclipse.ecf.osgi.services.distribution -> > org.eclipse.ecf.discovery dependency > -- Distribution uses ServiceEndpointDescription to determine endpoint identity > (instead of IServiceID). Internally ECF's SED still delegates identity to > IServiceID > -- ServiceEndpointDescriptionImpl has been renamed to > ECFServiceEndpointDescription and turned into an abstract superclass > -- ECFServiceEndpointDescriptionImpl has been moved to the internal package > > - General code cleanup > > My use case is SEN's newly contributed file based discovery provider. It does > not implement ECF discovery (yet?). Btw. thanks Thomas. > Patches applied, tested, and released to HEAD. Thanks Markus.
Updated OSGi Compendium classes (org.osgi.service.discovery and org.osgi.service.distribution) in org.eclipse.ecf.osgi.services bundle to version 20090331 as per CQ http://dev.eclipse.org/ipzilla/show_bug.cgi?id=2795 Also uupdated dependent implementations in org.eclipse.ecf.osgi.services.discovery org.eclipse.ecf.osgi.services.distribution
Created attachment 131191 [details] IRemoteServiceContainer finder Here's a proposed initial implementation of the idea of an IRemoteServiceContainerFinder see this discussion on the ecf-dev mailing list for context: http://dev.eclipse.org/mhonarc/lists/ecf-dev/msg02206.html This patch supplies an IRemoteServiceContainerFinder interface and the installation of a default service instance (provided using the existing DiscoveredServiceTrackerImpl.findRSCA for the time being). Note this is, for the moment, only implemented as an OSGi service. We may wish to also add an extension point to allow IRemoteServiceContainerFinders to be declared via extensions in addition to the OSGi service registry.
I would like to propose some minor refactorings/renamings of ECF classes ...just to avoid some amount of pain later on: In discovery 1) Change ECFServicePublication to IServicePublication (it would still extend osgi's ServicePublication) 2) Create an interface, IServiceEndpointDescription extends ServiceEndpointDescription, and refer to IServiceEndpointDescription *rather* than ECFServiceEndpointDescription (i.e. either remove ECFServiceEndpointDescription totally, or move the actual impl into an internal package). In distribution 1) Rename ECFServiceConstants (interface) to IServiceConstants Any objections to any of this? Markus I'm particularly looking to you for objections...as this could conflict with some of your plans WRT (e.g.) file based discovery integration.
Created attachment 134797 [details] our contribution with new headers Hi all, this is the updated version of our contribution based on the latest OSGi spec changes with the new headers. We apologize for the late response. Hope to hear you soon. Mit freundlichen Grüßen / With best regards Thomas Kießlich Siemens Enterprise Communications GmbH & Co. KG HiPath Applications SEN LIP DA 11 Schertlinstr. 8 81379 Munich, Germany Phone: +49 (89) 722-32483 Fax: +49 (89) 722-40560 Email: thomas.kiesslich@siemens.com Communication for the open minded www.siemens.de/open www.siemens.com/open Siemens Enterprise Communications GmbH & Co. KG; Registered office: Munich; Commercial registry: Munich, HRA 88546; WEEE-Reg.Nr. DE 27980375; General Partner: Siemens Enterprise Communications Management GmbH; Managing Directors: James R. O’Neill, Stephen Jones, Todd Schorr; Registered office: Munich; Commercial registry: Munich, HRB 163415 Siemens Enterprise Communications GmbH & Co. KG is a Trademark Licensee of Siemens AG Important notice: This e-mail and any attachment thereof contains corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank you.
Added dependency on bug #275494.
Two things: 1) There is new getting started wiki page: http://wiki.eclipse.org/Getting_Started_with_ECF%27s_RFC119_Implementation Please review, comment, amend. 3) I propose that this plan bug be resolved as fixed for ECF 3.0, and that a new bug/bugs be created for specific enhancements/additions/bug fixes as they arise.
Marking this bug as resolved, as ECF 3.0, 3.0.1, 3.1 all include the functioning impl of RFC119.
