1 Reply Latest reply on Dec 21, 2011 7:51 PM by Freeman(Yue) Fang

    Feedback on updating a bundle

    jamie archibald Apprentice

      I sometimes run into cases where I have a bundle (e.g. ABC) that depends on another bundle (e.g. DEF). When I update bundle DEF and restart ABC the ABC bundle doesn't get the new DEF bundle. I have confirmed this as the new DEF bundle contains code changed from a SNAPSHOT via maven.

       

      I was wondering if there is any way when executing a "update <bundle-id> " that SMX can automatically output to the console what the updated version is contained in the manifest?

       

      Somehow I think SMX is not updating the DEF. I've had to shut down SMX in order for ABC to get the DEF changes.

        • 1. Re: Feedback on updating a bundle
          Freeman(Yue) Fang Master

          Hi,

           

          This this expected behavior per OSGi spec, you need refresh bundle DEF to ensure the changes take effect.

           

          Here is how it works under the hood.

           

          If the snapshot bundle you're updating still used(such as import package) by other bundles. Let's say the snapshot bundle is bundle A, and another bundle B import package from Bundle A. So the scenario is that

           

          Before you update Bundle A, in OSGi container

           

          Bundle A in Revision1<============Bundle B in Revision1

           

          After you update Bundle A, in OSGi container

          Bundle A in Revision1<============Bundle B in Revision1 and there's also a Bundle A in Revision2(so here in the OSGi container two revisions for BundleA, but only  Revision1 take effect)

          at this moment Bundle B in Revision1 still refer the Bundle A in Revision1, you need explicitly refresh Bundle A which in turn will cause all other bundles use(and transitively use) Bundle A to re-resolve(this operation is really heavy loaded work as so many bundles might be resolved again, it depend on if BundleA play a very basic bundle role), after that the new revision2 for BundleA take effect.

           

          So after you refresh BundleA, in OSGi container,

          Bundle A in Revision2<============Bundle B in Revision1

          At this moment you changes for that snapshot BundleA take effect.

           

          This kind of two-steps update/refresh operation avoid unnecessarily frequently resolving lots of bundles(as it's cpu consuming task), you can updated several bundles and then refresh  once to get all changes take effect as one goal, and this behavior is totally from OSGi spec.

           

          The different scenario is that if the SNAPSHOT Bundle A is self-used, no other Bundles import package or OSGi service from Bundle A, then update BundleA means the new revision will take effect immediately.

           

          Hope this helps

          Freeman