karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Discuss: Use DS for karaf bundles
Date Fri, 18 Mar 2016 19:33:28 GMT
2016-03-18 13:38 GMT+01:00 Guillaume Nodet <gnodet@apache.org>:

> 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

> 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 Schneider

Open Source Architect

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