> - align the ListenerHook interface with the final version used in Equinox I've added CXF-1896 for this.
> - find some alternative mechanism for transparent registration of remote > services looked up directly (i.e. via BundleContext.getServiceReferences() as > opposed to a ServiceTracker/Listener) This is an issue with the design of RFC 126 and needs to be discussed in the OSGi Alliance. However, is it really an issue that would block the contribution to Felix? I personally don't think it's a blocker for moving the code to Felix. > - probably a bit more test coverage Added CXF-1897 Thanks, David 2008/11/3 Eoghan Glynn <[EMAIL PROTECTED]>: > > > Hi David, > > It would be great to have RFC 126 support in Felix as well as Equinox, as > obviously this would remove a barrier to wide adoption of dOSGi. > > So I agree, it would be a good move to contribute back the ListenerHook > support from the forked version of Felix that we've put in the CXF sandox. In > practical terms, it would be more straight-forward for us to take a > dependency on another maven-friendly Apache project. However, there are a few > bits of work required before the Felix-based ListenerHook support could be > submitted to Felix: > > - align the ListenerHook interface with the final version used in Equinox > > - find some alternative mechanism for transparent registration of remote > services looked up directly (i.e. via BundleContext.getServiceReferences() as > opposed to a ServiceTracker/Listener) > > - probably a bit more test coverage > > We'd then be relying on the Felix community to flesh out the initial > contribution, so as to form a fully-fledged RFC 126 implementation (e.g. add > support for the FindHook, which we don't use directly in distributed OSGi, > but would be useful in other contexts). > > But I also think we really should be leveraging the existing Equinox 126 > implementation in the near-term, for example to validate the initial > re-basing of dOSGi on the new version of the ListenerHook. Also, the earlier > we smoke out any issues in the Equinox service hooks (e.g. in advance of the > OSGi EEG f2f meeting next week), the better chance we have of getting a rapid > fix. > > Cheers, > Eoghan > > -----Original Message----- > From: David Bosschaert [mailto:[EMAIL PROTECTED] > Sent: Mon 03/11/2008 04:28 > To: [email protected] > Subject: Getting the Distributed OSGi component out of the CXF sandbox > > Hi all, > > The DOSGi sanbox project is getting closer to being a fully functional > Reference Implementation of the Distribution Software (DSW) component > of Distributed OSGi (RFC 119). > The main thing that prevents it from moving out of the sandbox is the > fact that it currently uses a modified version of Felix. Distributed > OSGi depends on a new addition to the OSGi Core Spec: the Service > Registry hooks (RFC 126). It uses this to transparently notify any > registered Discovery systems of the OSGi services that consumers are > interested in so that these Discovery systems can register just those > remote services that make sense to the current application. > For this purpose, the modified Felix code in the CXF DOSGi sanbox > codebase contains the bits of RFC 126 that it needs to function. It's > not a full RFC 126 implementation though. > > Felix itself doesn't yet contain an implementation of RFC 126 and my > understanding is that the project would potentially be interested in > our work regarding Service Registry hooks. Therefore one idea would be > to take our RFC 126 bits and submit them to the Felix project. We > should then ultimately be able to simply depend on Felix and all of > the DOSGi code will then be ready to move out of the sandbox. > > BTW the latest builds of Equinox do actually contain an implementation > of the full RFC 126 specification, so the DOSGi code should already > work with Equinox. > > Thoughts anyone? > > David > > >
