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? > 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/... 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-
