On 2/22/2016 8:01 AM, Christian Schneider wrote:
Aries sounds like a good place for this.
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.
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.
The ECF remote service API has dependencies as described here [2]. We
would be happy to support and/or enhance/extend as needed to sync up.
Scott
[1] http://download.eclipse.org/rt/ecf/3.12.1/javadoc/index.html
[2] http://wiki.eclipse.org/Distribution_Providers#Remote_Services_API
So if this code is independent from CXF and implements an OSGi
specification it would fit great into Aries.
I have not yet looked into the Redhat code but I think at the very
least we could take the RMI impl from there.
Christian
----
public interface ConfigurationTypeHandler {
public Object createProxy(
ServiceReference<?> reference,
BundleContext bundleContext,
Class<?> interfaceClass,
EndpointDescription endpoint);
public ExportResult createServer(
ServiceReference<?> serviceReference,
BundleContext bundleContext,
Map<String, Object> serviceProperties,
Class<?> interfaceClass,
Object service);
}
---
public class ExportResult {
private Map<String, Object> eProps;
private Closeable server;
private Throwable ex;
public ExportResult(Map<String, Object> eProps, Closeable server) {
this.eProps = eProps;
this.server = server;
}
public ExportResult(Map<String, Object> eProps, Throwable ex) {
this.ex = ex;
}
public Throwable getException() {
return ex;
}
public Closeable getServer() {
return server;
}
public Map<String, ?> getEndpointProps() {
return eProps;
}
}
On 22.02.2016 15:52, Guillaume Nodet wrote:
You see things backward. RedHat has not proposed to donate the code.
I've been asked on this list if RedHat would actually donate the
code. That's quite different. As for why the code suits Johannes and
Sasha's need better than the CXF or the Cellar one, I'm sure they can
answer that part if not already done. And you're right we don't
really need to start any legal stuff at this point. We first need to
decide if the Karaf community wants this code along with 2 committers
to maintain it. Actually, I think Aries may be a better choice for
this code, especially if the goal is to somehow merge efforts from
CXF / Karaf communities.
Kind regards,
Łukasz
—
[email protected]
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
