Uploaded image for project: 'Red Hat Fuse'
  1. Red Hat Fuse
  2. ENTESB-2387

Karaf command "osgi:list -l" still shows location of old bundles even after patch is installed successfully in fabric

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • jboss-fuse-6.2
    • jboss-fuse-6.1
    • Karaf
    • None
    • % %

    Description

      Karaf command "osgi:list -l" is used to show location of bundles. However, after I successfully installed a patch in my fabric environment. it still shows old bundle version. Although it worked fine in a standalone container after a patch being installed.

      Here is steps for applying the patch:

      1. unzip jboss-fuse-full-6.1.0.redhat-379.zip
      2. bin/fuse
      3. fabric:create --wait-for-provisioning
      4. fabric:version-create 1.1
      5. patch-apply --version 1.1 --username admin --password admin file:/apps/patches/jboss-fuse-6.1.0.redhat-379-r1.zip
      6. fabric:container-upgrade 1.1 root

      Here are some output:

      JBossFuse:karaf@root> osgi:list |grep camel-core
[ 142] [Active     ] [            ] [       ] [   50] camel-core (2.12.0.redhat-610394)
JBossFuse:karaf@root> osgi:list -l |grep camel-core
[ 142] [Active     ] [            ] [       ] [   50] mvn:org.apache.camel/camel-core/2.12.0.redhat-610379
JBossFuse:karaf@root> osgi:list |grep 262
[ 262] [Active     ] [            ] [       ] [   60] JBoss A-MQ Fabric HTTP Discovery (6.1.0.redhat-394)
JBossFuse:karaf@root> osgi:list -l |grep 262
[ 262] [Active     ] [            ] [       ] [   60] mvn:org.jboss.amq/mq-http-discovery/6.1.0.redhat-379

      You can see the incorrect output by command "osgi:list" with -l option.

      However, if I repeat the test with slightly different steps:

      1. unzip jboss-fuse-full-6.1.0.redhat-379.zip
      2. bin/patch /apps/patches/jboss-fuse-6.1.0.redhat-379-r1.zip
      3. bin/fuse
      4. fabric:create --wait-for-provisioning
      5. fabric:version-create 1.1
      6. patch-apply --version 1.1 --username admin --password admin file:/apps/patches/jboss-fuse-6.1.0.redhat-379-r1.zip
      7. fabric:container-upgrade 1.1 root

      Here are some output:

      JBossFuse:karaf@root> osgi:list |grep camel-core
[ 142] [Active     ] [            ] [       ] [   50] camel-core (2.12.0.redhat-610394)
JBossFuse:karaf@root> osgi:list -l |grep camel-core
[ 142] [Active     ] [            ] [       ] [   50] mvn:org.apache.camel/camel-core/2.12.0.redhat-610394

      You can see that the "osgi:list -l" on the camel-core bundle did show a correct version. However this bundle still shows wrong version though:

      JBossFuse:karaf@root> osgi:list -l |grep 264
[ 262] [Active     ] [            ] [       ] [   60] mvn:org.jboss.amq/mq-http-discovery/6.1.0.redhat-379
JBossFuse:karaf@root> osgi:list |grep 264
[ 262] [Active     ] [            ] [       ] [   60] JBoss A-MQ Fabric HTTP Discovery (6.1.0.redhat-394)

      Attachments

        Issue Links

          relates to

          Bug - A problem that impairs or prevents the functions of the product. ENTESB-2397 Changing feature repo version in fabric profile doesn't trigger change in bundles

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Bug - A problem that impairs or prevents the functions of the product. ENTESB-3804 After applying patch, bundle "version" and "location" do not match

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Bug - A problem that impairs or prevents the functions of the product. ENTESB-11309 Hawtio osgi tab showing old versions in Location

          • Minor - To be worked after urgent, high, and medium priorities are resolved. This term is chosen when the severity of the issue is low, or the complexity or effort to correct it may be higher, relatively speaking. For low priority issues, known workarounds exist or are not needed due to the trivial effort needed to address the issue.
          • Closed

          Activity

            People

              g_nodet Guillaume Nodet (Inactive)
              rhn-support-qluo Joe Luo
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: