2016-03-18 13:38 GMT+01:00 Guillaume Nodet <[email protected]>: > I agree with Achim and Lukasz. > > Here are the advantages of the current solution: > > 1/ No additional dependency. One thing that I really care about is that > the bundles in Karaf are independent. I.e. they do not rely on an > extender. The benefit is that you can upgrade the bundles independently > and you don't have an additional bundle which cause all the bundles to be > refreshed / restarted. > Does that refresh happen with DS? Of course the bundles would kind of restart when you update DS but that is a very uncommon thing. Normally you only update user bundles.
> > 2/ Very lightweight. The current framework only consist in 3 classes : > BaseActivator, SingleServiceTracker, > SingleServiceTracker$SingleServiceListener. > Even the annotations are not included at runtime. > I dont think that DS really slows down the startup. In Aries RSA I use DS for the example bundle and still get a test time of 1.5s even when spinning up two containers. You are right though that the startup time improved a lot compared to blueprint. > > 3/ Very fast. No xml parsing, no reflection. Just the > OSGI-INF/karaf-tracker/ property file which is loaded by the activator. So > it's really fast at startup. > As far as I recall the support for karaf commands is implemented using an extender like in DS. So I do not fully understand where the difference is. > > 4/ Very robust. Quite the contrary to what you say, I think this very small > framework is way more robust than blueprint or DS. I spent quite some time > load-testing karaf 4 before the release, using the bundle:load-test > command. > I did not say that the current solution is not robust. It is just not proven as much as DS as it is only used in our environment. > 5/ DS exclusively uses the OSGi registry for wiring. There's no notion of > "internal" wiring, everything is exposed. So by default, the capabilities > / requirements contain much more than what is needed, with the additional > semantical change where the bundle could be wired to components coming from > different bundles (check the bundle manifest in your branch). > That is indeed a bit of a drawback of DS compared to blueprint. I dont think the current karaf util approach is any better though as it also does not provide internal DI support and I hope we never create another DI solution. There are enough out there already :-) In any case it does not seem like we can reach a consensus so lets keep everything like it is. Maybe we can talk about that again when we plan the next major version. Christian -- -- Christian Schneider http://www.liquid-reality.de <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
