karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: Discuss: Use DS for karaf bundles
Date Fri, 18 Mar 2016 12:38:48 GMT
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.

2/ Very lightweight. The current framework only consist in 3 classes :
BaseActivator, SingleServiceTracker,
 Even the annotations are not included at runtime.

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.

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.

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).

So yes, the main drawback are : limited scope and not documented, but given
is has never been written to be used outside karaf, I don't see those as
real problems.   If the concern is users, I'm all for advertising the use
of DS or Blueprint for our users, I don't think they should use our
internal framework which is much more low level.

2016-03-17 16:43 GMT+01:00 Christian Schneider <chris@die-schneider.net>:

> We currently use some custom Activator base classes to wire the karaf
> bundles. The goal of this was to avoid depending on blueprint
> as it is a quite heavy dependency and makes it harder to use a different
> blueprint impl or version.
> There are some problems with this approach though:
> - It makes it harder for new people to understand what we are doing
> - The custom code is more error prone than a proven framework
> So I propose to switch our own bundles to use DS to expose and wire
> services.
> There are some advantages:
> - The DS annotation approach is easier to understand and more self
> documenting than the custom code
> - We get rid of the classes in util for the custom code
> - The scr commands help diagnose problems
> The main cost is that we need to always install the felix scr bundle.
> To prove that it can work I switched bundle core in a branch
> https://github.com/apache/karaf/tree/EXPERIMENTAL_DS .
> The DS based code works quite nicely.
> Btw. I found a small problem with our shell command extender. It only
> seems to work on all commands or none. If there is any required service
> missing then none of the commands is installed.
> This made it hard for me to diagnose problems as I was missing all bundle
> commands ;-)
> So while working on the switch I thought about two improvements to the
> extender:
> 1. Work on each command individually. So each command can activate as soon
> as the deps are met
> 2. Provide a service and commands to diagnose problems like the scr
> commands
> Christian
> --
> Christian Schneider
> http://www.liquid-reality.de
> Open Source Architect
> http://www.talend.com

Guillaume Nodet
Red Hat, Open Source Integration

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

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