Re: Blueprint vs. Spring

[Sergey Zhemzhitsky <sz...@gmail.com>]

Hello Johan, Christian,

Thanks a lot for the links and explanations!

It seems, that still, there is no silver bullet.
Pax exam is pretty cool for integration testing, but test+development phases are much slower than with spring if
we are doing for example some kind of functional testing.

And even with the example of cxf+namespaces - there are always some backing classes under the hood, so two
options are available to configure the cxf (and other components) - by means of namespaces - and this is where
the blueprint shines, and by means of classes - here the behavior of the blueprint and spring should be the same.
But there is not only cxf which provides namespace handlers, there are a lot of libs, which have pretty poor
capabilities to be configured by means of namespaces, and should be configured by declaring of the beans with
the appropriate classes (as an example let's take drools).

So, for each individual case, an appropriate approach should be taken.

Regards,
Sergey

> On 27.09.2013 07:31, Sergey Zhemzhitsky wrote:
>>>> The big problem is the conversion of matrix classloading to an ee classloader and context resets
>> I suppose, this issue is relevant to improperly implemented libs only (without OSGi in mind)
>> and neither spring nor blueprint do not solve this issue of of the box.
>>
>> Kind Regards,
>> Sergey
> Unfortunately this is not only an issue with non OSGi ready libs.

> A good example is apache CXF. CXF defines some custom spring and 
> blueprint name spaces to make it easier to describe your endpoints and
> proxies.

> In spring dm the impl classes behind the namespaces are loaded using the
> classloader of your user bundle. This means your user bundle has to 
> import all the internal packages of cxf. This even can not be automated
> as you do not see these dependencies in the code. So you either end with
> require bundle on all cxf bundles or you have to figure out the import
> package statements by trial and error.

> Blueprint in comparison loads the impls behind the namespaces using the
> classloader of the bundle where the impls are located. So your suer 
> bundle does not need to care about the internals. In fact when you look
> at sample applications using blueprint and cxf you normally do not have
> to configure anything by hand.
> Just use the maven bundle plugin and your imports are generated. See 
> https://github.com/cschneider/Karaf-Tutorial for some examples.

> In fact I think that spring dm is responsible for a lot of the bad 
> experiences people had with OSGi.

> So my recommendation is to use blueprint only or e.g. declarative 
> services and do your itests with pax exam. Pax exam is of course another
> step to learn but it works great and your tests are very near the actual
> OSGi platform. So you see most issues already in the itests.
> If your test spring dm contexts outside OSGi then many issues will not
> show because the classloading is different.

> Christian