Quantcast

Bundle sometimes doesn't start

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bundle sometimes doesn't start

IgorS
This post was updated on .
Hi, i'm relatively new to OSGi and Karaf, therefore please forgive me if this problem was answered elsewhere (i looked but couldn't find)

I was working in past few days with Karaf and deploying OSGi bundles(containing routes) using different DI frameworks within Karaf: blueprint and spring.

I'm running Karaf 4.1 on Windows 7 and java 1.8.

As far i understand blueprint is recommended but i had to check spring as well In order to 'integrate' Spring and OSGI. Eventually i managed to get it working.

Feature list is the following (my bundle is FileRouteSpring and it contains very simple route , just copy file(s) from->to):
karaf@root()> list
START LEVEL 100 , List Threshold: 50
 ID | State  | Lvl | Version        | Name
----+--------+-----+----------------+----------------------------------------
 29 | Active |  80 | 4.1.0          | Apache Karaf :: OSGi Services :: Event
 53 | Active |  50 | 2.18.2         | camel-blueprint
 54 | Active |  50 | 2.18.2         | camel-catalog
 55 | Active |  50 | 2.18.2         | camel-commands-core
 56 | Active |  50 | 2.18.2         | camel-core
 57 | Active |  80 | 2.18.2         | camel-karaf-commands
 64 | Active |  50 | 2.18.2         | camel-spring
 86 | Active |  50 | 2.18.2         | camel-spring-dm
 87 | Active |  50 | 1.1.1          | geronimo-jta_1.1_spec
109 | Active |  80 | 0.0.1.SNAPSHOT | FileRouteSpring

But, sometimes after Karaf is restarted bundle can't start due to errors like this:
("org.apache.camel.model.config" doesnt contain ObjectFactory.class or jaxb.index)

It looks like its timing issue. I guess OSGI runtime(Felix) is resolving all bundle dependencies during boot based on start level and i suspect that sometimes resolution part fails(or wrong class is wired). There are several bundles that have same level (50) hence that could explain the timing problem. Or, maybe this i'm completely off mark with my thoughts :)

I was wondering if anyone experienced this problem or maybe can give his thoughts.

I was thinking to switch to Equinox or to give different start levels per bundle.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bundle

cschneider
In OSGi dependencies are resolved in the resolve state of a bundle. So this resolution is completely independtent of eventual start levels.
When a bundle is started then the only thing happening is that the activator is executed or in case of spring dm or blueprint the context is started.

Equinox as well as felix allow to set start levels for bundles so there shoud be no difference in that regard.
The problem with spring is that it was never designed for OSGi and spring dm is a quite buggy way to bridge spring to OSGi. So it might be a good idea to try if switching to blueprint solves the issue. If you look into blueprint then you should also take a look at the blueprint-maven-plugin. It allows to use  a lot of the spring and JEE annotations to do the wiring and creates a blueprint xml at build time.

Christian

2017-03-04 0:01 GMT+01:00 IgorS <[hidden email]>:
Hi, i'm relatively new to OSGi and Karaf, therefore please forgive me if this
problem was answered elsewhere (i looked but couldn't find)

I was working in past few days with Karaf and deploying OSGi
bundles(containing routes) using different DI frameworks within Karaf:
blueprint and spring.

I'm running Karaf 4.1 on Windows 7 and java 1.8.

As far i understand blueprint is recommended but i had to check spring as
well In order to 'integrate' Spring and OSGI. Eventually i managed to get it
working.

Feature list is the following (my bundle is FileRouteSpring and it contains
very simple route , just copy file(s) from->to):
karaf@root()> list
START LEVEL 100 , List Threshold: 50
 ID | State  | Lvl | Version        | Name
----+--------+-----+----------------+----------------------------------------
 29 | Active |  80 | 4.1.0          | Apache Karaf :: OSGi Services :: Event
 53 | Active |  50 | 2.18.2         | camel-blueprint
 54 | Active |  50 | 2.18.2         | camel-catalog
 55 | Active |  50 | 2.18.2         | camel-commands-core
 56 | Active |  50 | 2.18.2         | camel-core
 57 | Active |  80 | 2.18.2         | camel-karaf-commands
 64 | Active |  50 | 2.18.2         | camel-spring
 86 | Active |  50 | 2.18.2         | camel-spring-dm
 87 | Active |  50 | 1.1.1          | geronimo-jta_1.1_spec
109 | Active |  80 | 0.0.1.SNAPSHOT | FileRouteSpring

But, sometimes after Karaf is restarted bundle can't start due to errors
like this:
("org.apache.camel.model.config" doesnt contain ObjectFactory.class or
jaxb.index)

It looks like its timing issue. I guess OSGI runtime(Felix) is resolving all
bundle dependencies during boot based on start level and i suspect that
sometimes resolution part fails(or wrong class is wired). There are several
bundles that have same level (50) hence that could explain the timing
problem. Or, maybe this i'm completely off mark with my thoughts :)

I was wondering if anyone experienced this problem or maybe can give his
thoughts.

I was thinking to switch to Equinox or to give different start levels per
bundle.



--
View this message in context: http://karaf.922171.n3.nabble.com/Bundle-tp4049740.html
Sent from the Karaf - User mailing list archive at Nabble.com.



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

Open Source Architect
http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bundle

IgorS
Thanks for quick reply.

I also deployed my bundle in Talend runtime (Runtime_ESBSE) and did several stop/start, bundle always is in active state and route is working fine. I did this manually i don't have scientific prove that it always works :)

If i execute 'feature:list' on Talend runtime and compare to features in my Karaf installation list is longer. Does this means that bridging Spring to OSGi in Talend runtime is done better (by installing additional features) ? Or, still this problem can occur even in Talend runtime?

Igor.
Loading...