On 2/22/2016 8:01 AM, Christian Schneider wrote:
In the mean time I looked a bit into the CXF DOSGi code. I think we
can split off the CXF part. So what remains is discovery support for
zookeeper and local discovery
and a core RemoteServiceAdmin impl that can be enhanced with
providers like CXF or for example an RMI or Hazelcast one.
I have extracted the interface the providers would need to implement.
I think we should be fine with something like blow. The details of
the interface of course can be discussed but the classes below
is what CXF DOSGi would need for the CXF support and it looks like
other providers should be possible too with such informations.
Thanks Christian for taking the time to look into this.
This is exactly what I was thinking. The topology manager is already
completely standalone, discover is defined in the spec and the RSA is
95% independent of
CXF itself. With a little refactoring it would be possible to use that
implementation with or without CXF-core and mix and match distribution
providers and discovery as needed.
Am 22.02.2016 um 19:09 schrieb Scott Lewis:
I also think that ECF has a similar set of interfaces. Maybe we can
even sync with them.
Yes it does. ECF has an API called the 'remote services API'
(org.eclipse.ecf.remoteservices bundle) [1], that the ECF Remote
Service Admin implementation uses to export and import remote services
(using whatever topology manager). All providers (us and others)
implement the appropriate parts of this remote services API, and they
then may be used as R6+-compliant RSA implementations...with any
desired discovery and/or topology manager.
It is unfortunate that the original spec did not already include such an
interface for distribution provider. However, if CXF-DOSGi and ECF could
agree on such an interface that would make it much easier to implement
RSA independent distribution providers and possibly even make it into
the specification eventually.
If the two of you see that as an option I guess there would be 2 ways it
could be done:
1. Create semantically identical interfaces in both CXF and ECF
namespace. Not ideal, but at least it makes it easy to provide an
implementation for both and no additional dependencies are needed on CXF
and ECF side.
2. Create the interface in another bundle and use it in both
implementations (in Aries maybe?).
@Christian
> I have extracted the interface the providers would need to implement.
I think we should be fine with something like blow.
Yes, those are exactly what I was using to bridge the fabric code and it
was a breeze to implement with those 2 classes.
ECF is quite a bit different implementation-wise but Scott would know
better if an interface like the CXF one could be made work in ECF.
Side-By-Side compare of integrating into CXF and ECF:
https://github.com/seeburger-ag/fabric8/blob/resurrect/fabric/fabric-cxf-hawt/src/main/java/com/seeburger/cxf/HawtConfigurationTypeHandler.java
https://github.com/seeburger-ag/fabric8/tree/resurrect/fabric/fabric-ecf-hawt/src/main/java/com/seeburger/ecf/container
Johannes
