glassfish
  1. glassfish
  2. GLASSFISH-17899

hk2/class-model.jar contains classes which are also present in hk2/auto-depends.jar with different versions causing osgi resolver error

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.1.1
    • Fix Version/s: 3.1.2_b13
    • Component/s: other
    • Labels:
      None

      Description

      See stack trace below which says that class-model classes are found in two different bundles with different package versions. That results in a constraint violation.
      [exec] Launching GlassFish on Felix platform
      [exec] Completed shutdown of GlassFish runtime
      [exec] Exception in thread "main" java.lang.reflect.InvocationTargetException
      [exec] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      [exec] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      [exec] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      [exec] at java.lang.reflect.Method.invoke(Method.java:597)
      [exec] at com.sun.enterprise.glassfish.bootstrap.GlassFishMain.main(GlassFishMain.java:97)
      [exec] at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:55)
      [exec] Caused by: com.sun.enterprise.module.ResolveError: Failed to start Bundle Id [248] State [INSTALLED] [org.glassfish.main.core.kernel(Kernel Classes):3.1.2.SNAPSHOT]
      [exec] at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:177)
      [exec] at org.jvnet.hk2.osgiadapter.OSGiModuleImpl$2$1$1.loadClass(OSGiModuleImpl.java:344)
      [exec] at com.sun.hk2.component.LazyInhabitant.loadClass(LazyInhabitant.java:124)
      [exec] at com.sun.hk2.component.LazyInhabitant.type(LazyInhabitant.java:99)
      [exec] at org.jvnet.hk2.component.Habitat$SelfListener.inhabitantIndexChanged(Habitat.java:1134)
      [exec] at org.jvnet.hk2.component.Habitat$3.inhabitantChanged(Habitat.java:599)
      [exec] at org.jvnet.hk2.component.Habitat$4.run(Habitat.java:640)
      [exec] at org.jvnet.hk2.component.SameThreadExecutor.execute(SameThreadExecutor.java:80)
      [exec] at org.jvnet.hk2.component.Habitat.doNotify(Habitat.java:630)
      [exec] at org.jvnet.hk2.component.Habitat.notify(Habitat.java:617)
      [exec] at org.jvnet.hk2.component.Habitat.notify(Habitat.java:603)
      [exec] at org.jvnet.hk2.component.Habitat.addIndex(Habitat.java:429)
      [exec] at org.jvnet.hk2.component.Habitat.addIndex(Habitat.java:422)
      [exec] at com.sun.hk2.component.InhabitantsParser.addIndex(InhabitantsParser.java:243)
      [exec] at com.sun.hk2.component.InhabitantsParser.add(InhabitantsParser.java:222)
      [exec] at com.sun.hk2.component.InhabitantsParser.parse(InhabitantsParser.java:174)
      [exec] at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.parseInhabitants(OSGiModuleImpl.java:376)
      [exec] at org.jvnet.hk2.osgiadapter.OSGiModulesRegistryImpl.parseInhabitants(OSGiModulesRegistryImpl.java:321)
      [exec] at com.sun.enterprise.module.common_impl.AbstractModulesRegistryImpl.createHabitat(AbstractModulesRegistryImpl.java:156)
      [exec] at com.sun.enterprise.module.bootstrap.Main.createHabitat(Main.java:425)
      [exec] at org.jvnet.hk2.osgiadapter.HK2Main.createHabitat(HK2Main.java:96)
      [exec] at com.sun.enterprise.glassfish.bootstrap.osgi.EmbeddedOSGiGlassFishRuntime.newGlassFish(EmbeddedOSGiGlassFishRuntime.java:89)
      [exec] at com.sun.enterprise.glassfish.bootstrap.GlassFishMain$Launcher.launch(GlassFishMain.java:113)
      [exec] ... 6 more
      [exec] Caused by: org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve bundle revision org.glassfish.main.core.kernel [248.0] because it is exposed to package 'org.glassfish.hk2.classmodel.reflect.util' from bundle revisions org.glassfish.hk2.auto-depends [221.0] and org.glassfish.hk2.class-model [5.0] via two dependency chains.
      [exec]
      [exec] Chain 1:
      [exec] org.glassfish.main.core.kernel [248.0]
      [exec] import: (&(osgi.wiring.package=org.glassfish.hk2.classmodel.reflect.util)(version>=1.0.0))
      [exec] |
      [exec] export: osgi.wiring.package=org.glassfish.hk2.classmodel.reflect.util
      [exec] org.glassfish.hk2.auto-depends [221.0]
      [exec]
      [exec] Chain 2:
      [exec] org.glassfish.main.core.kernel [248.0]
      [exec] import: (&(osgi.wiring.package=org.jvnet.hk2.config)(version>=1.0.0))
      [exec] |
      [exec] export: osgi.wiring.package=org.jvnet.hk2.config; uses:=org.glassfish.hk2.classmodel.reflect
      [exec] org.glassfish.hk2.config [112.0]
      [exec] import: (&(osgi.wiring.package=org.glassfish.hk2.classmodel.reflect)(version>=1.1.0))
      [exec] |
      [exec] export: osgi.wiring.package=org.glassfish.hk2.classmodel.reflect; uses:=org.glassfish.hk2.classmodel.reflect.util
      [exec] export: osgi.wiring.package=org.glassfish.hk2.classmodel.reflect.util
      [exec] org.glassfish.hk2.class-model [5.0]
      [exec] at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3832)
      [exec] at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
      [exec] at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
      [exec] at org.jvnet.hk2.osgiadapter.OSGiModuleImpl.start(OSGiModuleImpl.java:169)
      [exec] ... 28 more
      [exec]

      There are two solutions:
      I don't know who has changed hk2/auto-depends, but it bundles class-model and tiger_type classes. Although glassfish-hk2 packager is coded to exclude tiger_types.jar, it does not exclude class-model.jar. So, class-model.jar is also present in every distro that contains hk2. The issue is not this duplication of classes in two jars, the real problem is class-model.jar does not export the packages with a version unlike auto-depends.jar. It is perhaps an oversight by whoever added class-model module. So, we are some times facing issues in OSGi package resolution as it is thinking them as distinct packages. We have two ways to solve it:

      1) stop distributing class-model.jar in distro and optionally fix class-model.jar to export with proper version.
      or
      2) stop repackaging classes in auto-depends.jar and fix class-model.jar to export with proper version.

      #1 is preferable as it avoids one extra module.

        Issue Links

          Activity

          Hide
          Sanjeeb Sahoo added a comment -

          svn details:
          3.1.2 branch: r51283

          This does not have to be forward ported to trunk, as trunk uses a different version of HK2 which does not have the duplicate package issue.

          Show
          Sanjeeb Sahoo added a comment - svn details: 3.1.2 branch: r51283 This does not have to be forward ported to trunk, as trunk uses a different version of HK2 which does not have the duplicate package issue.

            People

            • Assignee:
              Sanjeeb Sahoo
              Reporter:
              Sanjeeb Sahoo
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: