karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milen Dyankov <milendyan...@gmail.com>
Subject Re: Discuss: Use DS for karaf bundles
Date Fri, 18 Mar 2016 18:49:01 GMT
Oh, got it now. Thanks for clearing this up. Btw, how do I get the minimal
distribution?

On Fri, Mar 18, 2016 at 7:33 PM, Jean-Baptiste Onofré <jb@nanthrax.net>
wrote:

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



-- 
http://about.me/milen

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