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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
