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 10:17:54 GMT
I would prefer DS but if we could agree on dependency manager then that 
would still be better than our custom code.
Btw. I would be interested to hear some more about your experiences and 
problems with DS. Till now I got most things running fine.
Maybe we can chat on irc or google hangouts and then recap what we found 
here.

Talking about Java 8 .. karaf 4.1 now requires java 8 so we should be 
able to use the new features.

Christian

On 18.03.2016 10:50, Łukasz Dywicki wrote:
> -1 With current codebase I must say that I can not support this idea. DS is more limited
than blueprint and custom activators we currently have. I already tried to wire some things
with DS and it is not possible - ie. making JAAS realm with login modules inside is not possible.
Starting thread from it or wiring in bundle context requires hand crafting or wrappers. Far
closer to what I would appreciate is Felix Dependency Manager [1][2], which will have similar
frames as our org.apache.karaf.util (base activator class) but better syntax and chances for
a bit wider community of users. There is also fresh module which supports Java 8 syntax which
is much more flexible than creating components by hand [3]. Some day, if we will switch to
Java 8 it will be blessing, for now it is just an extra module.
> For sure felix dependency manager is less popular than declarative services which are
part of osgi spec, however I’m sure it will have even smaller memory footprint than DS cause
it is still plain Java which does not require XML parsing, will be faster to start up, and
will offer similar or smaller complexity (see troubles with more advanced injections in DS).
> I must say that when I saw new Activators in Karaf 4 I was a bit lost, but at the end
it wasn’t that hard to pick it up and use karaf.util in my own stuff. What I do miss for
community is lack of documentation and example projects. More over in some places it is similar
to Felix Dependency Manager which makes me wonder if we could use it/join forces instead of
reinventing the wheel. For sure it is extra dependency which may conflict with users, but
may also interest people who use Felix DM to come and use Karaf. :-)
>
> [1] http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html
<http://felix.apache.org/documentation/subprojects/apache-felix-dependency-manager.html>
> [2] https://github.com/apache/felix/tree/trunk/dependencymanager <https://github.com/apache/felix/tree/trunk/dependencymanager>
> [3] https://github.com/apache/felix/tree/trunk/dependencymanager/org.apache.felix.dependencymanager.lambda.samples/src/org/apache/felix/dm/lambda/samples/hello
<https://github.com/apache/felix/tree/trunk/dependencymanager/org.apache.felix.dependencymanager.lambda.samples/src/org/apache/felix/dm/lambda/samples/hello>
>
> Best regards,
> Łukasz Dywicki
> --
> Apache Karaf Committer & PMC
> Twitter: ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
>
>
>> Wiadomość napisana przez Jean-Baptiste Onofré <jb@nanthrax.net> w dniu 17
mar 2016, o godz. 20:15:
>>
>> -0
>>
>> I'm puzzled here:
>> - on one hand, I see that it can help for development, improve support of scr for
some parts of Karaf (shell commands, etc), so it could be a good move
>> - on the other hand, it's a core dependency, as we had for blueprint, so with the
same problem: even the minimal distribution will require DS/SCR support.
>>
>> Anyway, if we go this way, it will be on a first major release (maybe 5.x as we removed
blueprint from 3.x to 4.x).
>>
>> Regards
>> JB
>>
>> On 03/17/2016 04:43 PM, Christian Schneider wrote:
>>> 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
>>>
>> -- 
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <mailto:jbonofre@apache.org>
>> http://blog.nanthrax.net <http://blog.nanthrax.net/>
>> Talend - http://www.talend.com <http://www.talend.com/>


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Mime
View raw message