karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: Proposal - Lightweight standalone remote OSGi implementation for karaf-cellar
Date Mon, 22 Feb 2016 08:33:48 GMT
2016-02-12 16:42 GMT+01:00 Sascha Vogt <sascha.vogt@gmail.com>:

> Hi all,
>
> we (a colleague of mine and myself) started searching for a
> high-performance / lightweight remote OSGi implementation. We have a
> requirement that the implementation has to /also/ (in addition to Karaf)
> run on a heavily customized JBoss 7.1.1 as well, so the lightweight part
> was kinda important ;)
>
> We stumbled accross http://moi.vonos.net/java/dosgi-fabric/ which talks
> about using the "old" dosgi implementation from Fabric8 (former Fuse
> ESB). We had a look and we really liked it. Performance wise it comes
> really close to RMI with about 30% overhead at 10k invocations of a
> service sending back and forth a simple string on the same host. Using
> different hosts the times were identical. Yes I know, that's not a
> "real" use case, but it made us confident in taking a deeper look. It
> also only has two external dependencies (hawtdispatch and hawtbuf, both
> ASL-2 licensed).
>
> So now the proposal: Resurrect the old Fabric8 implementation, directly
> at the karaf-cellar subproject. As the copyright of the original code
> belongs to RedHat, Guillaume could you ask internally if the following
> resources could be donated to the Karaf project?
>

I've asked RedHat about the possible donation. I'll keep you posted, but
keep in mind in case the outcome is positive, it can take quite a while
before the code is actually moved (the legal stuff tend to be much longer
than the technical stuff...)


>
> >
> https://github.com/fabric8io/fabric8/tree/4d878d1f47226a2c3fb77aeee76814419f5edce0
>
> Paths
> > /fabric/fabric-dosgi
> >
> /fabric/fabric-api/src/main/java/io/fabric8/api/ManagedCuratorFrameworkAvailable.java
> > /fabric/fabric-api/src/main/java/io/fabric8/api/scr/Configurer.java
> >
> /fabric/fabric-api/src/main/java/io/fabric8/api/scr/ValidatingReference.java
> >
> /fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/utils/ZooKeeperUtils.java
> >
> /fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/curator/Constants.java
> >
> /fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/curator/CuratorConfig.java
> >
> /fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/curator/CuratorFrameworkLocator.java
> >
> /fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/curator/ManagedCuratorFramework.java
>
> Test-Dependecies paths
> >
> /fabric/fabric-zookeeper/src/main/java/io/fabric8/zookeeper/bootstrap/BootstrapConfiguration.java
> > /fabric/fabric-api/src/main/java/io/fabric8/api/Container.java
> > /fabric/fabric-api/src/main/java/io/fabric8/api/ContainerOptions.java
> > /fabric/fabric-api/src/main/java/io/fabric8/api/HasId.java
> > /fabric/fabric-api/src/main/java/io/fabric8/api/ZkDefs.java
> > /fabric/fabric-api/src/main/java/io/fabric8/api/RuntimeProperties.java
> > /fabric/fabric-api/src/main/java/io/fabric8/api/DataStore.java
> > /fabric/fabric-api/src/main/java/io/fabric8/api/DataStoreTemplate.java
> >
> /fabric/fabric-zookeeper-spring/src/main/java/io/fabric8/zookeeper/spring/ZKServerFactoryBean.java
>
> The test dependencies could probably be done without, if they provide
> too big of a hassle, though it's better to start with running tests ;)
> They would also go into fabric-dosgi/src/test/java/...
>

It would be easier if we would get rid of the dependency to fabric-api /
fabric-zookeeper modules.
I'll see if this can be broken if the donation can be done.

An even easier way would be imho to donate the /fabric/fabric-dosgi (with
the dependency on fabric, which is ASL2 anyway), and then remove the
dependency inside the Karaf project.


>
> Given that RedHat would be willing to donate the code, we (mainly
> Johannes and me, both working for SEEBURGER AG) would work on it with
> the following roadmap in mind:
>
> 1. Make the implementation remote OSGi compatible (implement the defined
> interfaces, etc.)
> 2. Make the discovery exchangeable (so Zookeeper becomes an optional
> dependency). We need that part, as we have our own database based
> discovery, not really usable for the rest of the world. This would also
> allow to replace the currently available remote OSGi impl in Karaf and
> using the Cellar internals for discovery.
>



> 3. That is a bigger step / work and needs to be discussed further. There
> are at least two possible options
> 3. a) Inline the needed parts of hawt* as they seem to be an abandoned
> project too.
> 3. b) Make the transport exchangeable so the dependency to hawtbuf /
> hawtdispatch becomes optional and provide our own implementation
>
> Regarding hawt and option 3.a) inlining it: Guillaume do you know who
> owns the copyright to that? I assume also RedHat? Maybe those could also
> be donated?
>
> @all: What are your thoughts on that?
>
> Greetings
> -Sascha-
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message