karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: A Blueprint Free Karaf
Date Sat, 07 Dec 2013 15:15:22 GMT
I don't count the number of weeks I've spent during the last months fixing
pure OSGi code for concurrency and thread safety issues.  And that includes
Karaf, Pax-Web, Blueprint, Fabric and even SCR.   Service trackers are nice
tools, but not sufficient at all when it comes to handle multiple service
dependencies along with configuration changes.
Of course, registering commands is quite easy whatever method we use (pure
OSGi, DS, blueprint or any other tool).

Let's consider a simple use case: a bundle which expose an OSGi service
which has 2 service dependencies and a configuration.  Can you show me a
pure OSGi code that does it in a safe way ?


2013/12/7 Łukasz Dywicki <luke@code-house.org>

> All pax libraries we have deployed in Karaf are written without any piece
> of injection frameworks. Starting from pax logging over pax web, to pax
> wicket even (it supports blueprint namespaces but does not use it for
> service tracking).
> On other hand, does registration of commands is so hard that could not be
> done from Activator code? I don't think so. Most critical place which will
> be affected is actually a tracker, which will need to be registered by us.
> Indeed we'll get more code to maintain, but that's just matter of good
> modularization to keep it clean. Honestly, most of complications we have is
> hiden in service implementations. That's why I do consider dropping of
> dependency injection framework. It is something which can be done, it's
> just matter of balance between cons and pros.
> Best regards,
> Łukasz Dywicki
> --
> luke@code-house.org
> Twitter: ldywicki
> Blog: http://dywicki.pl
> Code-House - http://code-house.org
> Wiadomość napisana przez Christian Schneider <chris@die-schneider.net> w
> dniu 7 gru 2013, o godz. 13:14:
> > I went the pure OSGi way for  CXF DOSGi. It works but is quite error
> prone as you have to handle the dynamics of services and config yourself.
> As DOSGi is a pretty small project I think it was worth the effort for
> getting rid of DI dependencies.
> >
> > For karaf I would not like to have to do this for every service and
> command bundle. DS might work quite well there.
> > I have looked into the source from Ioannis. He uses SCR annotations for
> the wiring and the felix scr plugin to generate the xml. So it looks like
> not to much effort. The learning curve is of course there but I think with
> some good example projects it should be relatively easy.
> >
> > I have not yet seen how the SCR annotations handle config injection. I
> hope it works equally well.
> >
> > Christian
> >
> >
> > Am 06.12.2013 23:05, schrieb Łukasz Dywicki:
> >> Yes Joed,
> >> You got the point I wanted to reflect. DS and SCR is still dependency
> which, for sure, may be optional. Switching to poorer replacement from
> feature rich blueprint will bring bigger cost than moving to plain osgi.
> For me it will look like stopping in half of the way.
> >> Most of us knows well core spec plus something about blueprint. Very
> few from us knows anything more about SCR, except the fact, that it's
> exists. This kind of change may decrese number of maintaners to these who
> already know SCR. From drawbacks of another DI I may throw that it
> requires, if I'm not wrong, additional bundle header which lists all
> components. Also integration with maven bundle plugin seems missing. Ie for
> blueprint we get imports for free and validation, because when this plugin
> fails to read XML prevents build from passing.
> >>
> >> The idea of extender, shared earlier in this topic, which install
> necessary features is very good. It might be used in similar way as
> deployers or feature resolvers to preprocess bundles before installation to
> automatically enable certain features.
> >>
> >> Łukasz Dywicki
> >> --
> >> Code-House
> >> http://code-house.org
> >>
> >
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > Talend Application Integration Division http://www.talend.com
> >

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