2016-02-12 16:42 GMT+01:00 Sascha Vogt <sascha.v...@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: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
