Uploaded image for project: 'Karaf'
  1. Karaf
  2. KARAF-2475

Config bound to bundle after uninstall



    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.3.2
    • Fix Version/s: 2.4.0, 3.0.0, 2.3.4
    • Component/s: karaf
    • Environment:

      Centos 6 with Oracle JDK6.
      karaf-framework, obr and scr installed


      I have a Maven OSGi project that I wish to run in OSGi with Configuation Admin.

      It works first time, but after uninstall, the Configuration remains bound to a cached bundle and a subsequent attempt to use an updated version of the bundle fails.

      Once this happens, the only way I found to fix it (without blatting Karaf) was to install webconsole and force unbind of the config from the bundle, then restart the bundle... something which takes time and cannot be automated for CI.

      1. Bash: mvn clean install
      2. Karaf: refreshurl
      3. Karaf: deploy happy-bundle ( at version 1.0.201309171622)
      4. Karaf: start happy-bundle ( at version 1.0.201309171622)

      Everything is fine.
      I make a code change and then continue

      5. Karaf: stop happy-bundle ( at version 1.0.201309171622)
      6. Karaf: uninstall happy-bundle ( at version 1.0.201309171622) <- here is the problem?
      7. Bash: mvn clean install
      8. Karaf: refreshurl
      9. Karaf: deploy happy-bundle ( at version 1.0.201309171700)
      10. Karaf: start happy-bundle ( at version 1.0.201309171700)

      At this the Config fails to be bound, so happy-bundle is in an unhappy state.

      I get an error in $KARAF_HOME/data/log/karaf.log like:

      org.apache.felix.scr Cannot use configuration pid=happyConfig for bundle obr://com.example.happy-bundle/-1379426928105 because it belongs to bundle obr://com.example.happy-bundle/-1379423958102

      I'm assuming this is a Config Admin issue... not familiar enough with Karaf's source to dive in and check. I don't believe this is an SCR problem (it's just a user of Config Admin) and I've guessed it isn't, but it might be OBR!

      BTW: I did find running deploy without uninstall did work... however, it is likely that we'll wish to uninstall bundles completely (to ensure they're not interfering) and then reinstall later to restore their functionality works; or refactor code and use a pid with a renamed bundle that will require uninstall and then deploy of new bundle name.




            • Assignee:
              jbonofre Jean-Baptiste Onofré
              mark.richards Mark Richards
            • Votes:
              0 Vote for this issue
              4 Start watching this issue


              • Created: