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:33:42 GMT
The shell core headers don't import blueprint, and the shell feature 
doesn't depend to the blueprint feature.

What you see comes from the shell-compat feature which brings the "old" 
blueprint command extender (you are right, for backward compatibility, 
this feature is installed by default in the Karaf standard distribution).

What I meant is that if you remove the aries-blueprint and shell-compat 
features, Karaf is still running without these dependencies.

Regards
JB

On 03/18/2016 07:24 PM, Milen Dyankov wrote:
> This is what I mean:
>
> karaf@root()> bundle:info 44
>
> Apache Karaf :: Shell :: Core (44)
>
> ...
>
>
> karaf@root()> bundle:requirements 44 | grep blueprint
> osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.aries.blueprint)(version>=1.5.0)(!(version>=2.0.0)))
> resolved by:
>     osgi.wiring.package; org.apache.aries.blueprint 1.5.0 from
> org.apache.aries.blueprint.core [13]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.aries.blueprint.mutable)(version>=1.2.0)(!(version>=2.0.0)))
> resolved by:
>     osgi.wiring.package; org.apache.aries.blueprint.mutable 1.2.0 from
> org.apache.aries.blueprint.core [13]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.osgi.service.blueprint)(version>=1.0.0)(!(version>=2.0.0)))
> resolved by:
>     osgi.wiring.package; org.osgi.service.blueprint 1.0.0 from
> org.apache.aries.blueprint.core [13]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.osgi.service.blueprint.container)(version>=1.0.0)(!(version>=2.0.0)))
> resolved by:
>     osgi.wiring.package; org.osgi.service.blueprint.container 1.0.1 from
> org.apache.aries.blueprint.api [11]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.osgi.service.blueprint.reflect)(version>=1.0.0)(!(version>=2.0.0)))
> resolved by:
>     osgi.wiring.package; org.osgi.service.blueprint.reflect 1.0.1 from
> org.apache.aries.blueprint.api [11]
>
>
>
> On Fri, Mar 18, 2016 at 7:20 PM, Jean-Baptiste Onofré <jb@nanthrax.net>
> wrote:
>
>> 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
>>
>
>
>

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

Mime
View raw message