1

I am using Karaf 3.0.1 and have two fragment bundles A and B that attach to a host bundle C. I am able to install A, then B, then C, and start C and everything works fine.

When I stop and start Karaf though, the host usually has a failure and does not start successfully. Both fragments are listed as "Resolved" and show as being attached to the host and the host shows it is attached to the fragments, but the host has a state of "Failure". The exception in the log file is:

20140507 07:35:39.011 [ERROR] FelixStartLevel | 19:org.apache.aries.blueprint.core |
org.apache.aries.blueprint.container.BlueprintContainerImpl | Unable to start
blueprint container for bundle <host bundle name>
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to load
class <class from 2nd fragment> from recipe BeanRecipe[name='<bean ID from second
fragment blueprint XML>']

If I deploy only a single fragment, then I'm able to restart Karaf and the host starts fine. But with two fragments, Karaf will restart ok perhaps once or twice, but then fails and never successfully starts again. I played with start levels and having the host have a higher/later start level doesn't help at all.

I read When is an OSGi fragment attached to host? that seems to make it clear that start-levels don't affect resolution order and saw the suggestion to use Provide/Require-Capability headers. I tried that and see the same behavior, although again with a single fragment it works fine.

What else might I do to get this to work? Might there be a bug in Karaf/Felix regarding multiple fragments for the same host on restart?

Yes, I'd rather not use fragments but am porting a fairly complex Java EE app to OSGi and this is the approach that works given the code-base I have, but if I can't depend on things starting correctly when Karaf starts, this won't be workable.

Thanks,

Kevin

Community
  • 1
  • 1
schmke
  • 11
  • 3
  • I still think the startlevel will help, because this makes sure the fragment is actually available before the host bundle. – Achim Nierbeck May 09 '14 at 06:42
  • A colleague tried to reproduce my issue and was only able to if he had embedded jars in the fragment bundles. The first fragment bundle loads fine, but the second gets the error. He was able to get around this by adding *;scope=compile|runtime;inline=true to the pom. In my case, I went ahead and refactored a bunch of code so I can deploy the A and B bundles are regular bundles rather than fragments. Still seems like a Felix bug somewhere though. – schmke May 09 '14 at 17:19

0 Answers0