karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Discuss: Use DS for karaf bundles
Date Fri, 18 Mar 2016 18:20:21 GMT
Hi Milen,

Karaf Shell Core (if you mean this bundle) doesn't depend on blueprint 
(blueprint is not defined as a <dependency/> and so not in the manifest, 
even for the command extender).

Regards
JB

On 03/18/2016 07:14 PM, Milen Dyankov wrote:
> I personally think DS is pretty much what OSGi Alliance is going to promote
> (together with the enRoute project) and from that perspective if any
> component framework's user base is going to grow that would be DS. But if
> you guys want to still do it the "hard way" that's fine too. It just means
> less people will be able to contribute.
>
> As for things that can not be done with DS, I don't think Christian meant
> to say everything must be rewritten! If something needs to be done
> differently (activators/tackers/...) than it can/should be. It's not all or
> nothing scenario IMHO.
>
> Finally about Blueprint. I keep reading in posts that Karaf got rid of
> Blueprint. Meanwhile in 4.0.4 the "Apache Karaf :: Shell :: Core" still
> depends on Blueprint. So when you say "the bundles in Karaf are independent"
> what exactly do you mean?
>
> Best,
> Milen
>
>
>
> On Fri, Mar 18, 2016 at 1:38 PM, Guillaume Nodet <gnodet@apache.org> wrote:
>
>> 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,
>> SingleServiceTracker$SingleServiceListener.
>>   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/
>>
>
>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message