2013/12/7 Łukasz Dywicki <l...@code-house.org> > Going directly to your quesstion > > My solution would be: > - Create proxy factory which takes interface then, returned proxy should > open service tracker and take care of tracking. > - For configuration - simply use ManagedService, after all - that's what > aries is doing - thing we get from it is property injection. > > There is no "pure" osgi code which will satisfy your needs. Simply by fact > that you have different things which comes from different parts of spec, > which are deatached from each other. Service registration have nothing to > do with it's configuration. Now we are, let say, safe because aries masks > that. It doesn't really mean that we'are not having souch issues as you had > with pax-web. It's just handled by Aries, and even if Aries is very good, > it sometimes just fails as every generic purpose tool. I don't push many > contibutions to Karaf these days, however I heavily use it on daily basics, > and I am hit by some problems (NullPointers in cm-blueprint internals, > hangouts when using dev:watch, lack of initial update call when > cm:managed-properties are used). Fact that we don't see threading issues > with Aries doesn't really mean it doesn't have it. If you close eyes, world > still exists. This is proven. :-) >
What I meant by pure, is just not reusing an existing framework to help with the work, i.e. going straight to the OSGi Framework and CM apis. I don't say there are no issues in Aries, quite the opposite. What I really want to express is the fact that writing robust code in OSGi is *really* difficult. So it just does not make any sense to me to try multiplicating such code instead of reusing a good framework which does that for us, whatever it is. > > Here, going into detail - Aries in our use case in 90% is limited to > startup time. So if the service we would like to publish depens on two > mandatory references we just should hold registration untill dependencies > are satisfied. We know what dependencies are, proxy factory keeps eye on it > so we'll catch moment when everything pops in. Just by counting open/close > calls we will be able to call registration callback. We can at least try > doing that. In theory, if we'll solve most complicated use case, we now > have in Karaf, other things should raise smaller issues. > As I said, when I wrote "pure", I meant without Aries, DS or any framework, which is what you're proposing if I understood correctly. I'm not talking about something that works, but something which is robust, i.e. thread safe and not opened to deadlocks. If you are willing to go into more details, we can try to write such a small thing and see the resulting complexity of the code. > On configuration side - declarative services are all about services, so > we'll need to register ManagedService instance anyway and handle updaes on > our own. > > Fwiw, DS manages configuration too (not to the level of blueprint, it's mostly a bulk update), so you have no need to implement a ManagedService directly. > Cheers, > Łukasz Dywicki > -- > l...@code-house.org > Twitter: ldywicki > Blog: http://dywicki.pl > Code-House - http://code-house.org > > Wiadomość napisana przez Guillaume Nodet <gno...@apache.org> w dniu 7 gru > 2013, o godz. 16:15: > > > 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 ? > > > > Guillaume > > > > > > 2013/12/7 Łukasz Dywicki <l...@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 > >> -- > >> l...@code-house.org > >> Twitter: ldywicki > >> Blog: http://dywicki.pl > >> Code-House - http://code-house.org > >> > >> Wiadomość napisana przez Christian Schneider <ch...@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 > >>> > >> > >> > >
