Hi
- align the ListenerHook interface with the final version used in Equinox
I've added CXF-1896 for this.
this should be just about renaming 3 standard methods and dropping the one we
introduced to support the direct lookups.
- 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.
We very briefly chatted about it with Eoghan - perhaps there's a case for introducing another simple hook like DirectLookupHook to
preserve the semantics of ListenerHook ? Perhaps extending a FindHook with a new method might do too ?
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.
No it shouldn't - we'd just need to change or drop the simple pojo demo and possibly update one of the spring dm system tests, as a
result of dropping our private ListenerHook method dealing with direct lookups
Cheers, Sergey
- 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
