Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 3.1
    • Fix Version/s: not determined
    • Component/s: OSGi
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Linux

    • Issuezilla Id:
      14,181

      Description

      When running Glassfish under Eclipse PDE, I noticed that the number of installed
      bundles is less than when running it from the command line.

      The reason is that some of the modules/*.jar files are missing the required OSGi
      manifest headers, but both Equinox and Felix still install and even resolve them:

      58|Resolved |
      1|file:/home/hwellmann/glassfish-3.1-b24/glassfish/modules/jtype.jar (0.0.0)
      102|Resolved |
      1|file:/home/hwellmann/glassfish-3.1-b24/glassfish/modules/concurrent.jar (0.0.0)
      112|Resolved |
      1|file:/home/hwellmann/glassfish-3.1-b24/glassfish/modules/gf-client.jar (0.0.0)
      203|Resolved |
      1|file:/home/hwellmann/glassfish-3.1-b24/glassfish/modules/upgrade-tool.jar (0.0.0)
      209|Resolved |
      1|file:/home/hwellmann/glassfish-3.1-b24/glassfish/modules/javahelp.jar (0.0.0)

      This looks like a bug in Felix and Eqinox, or at least non-compliant extension
      of the OSGi spec.

      Anyway, what's the point in a bundle that does not export any packages or
      register any services?

      If these JARs are used at all, they only make sense outside of OSGi, so they
      should be moved to a different place.

        Activity

        Hide
        Richard S. Hall added a comment -

        A standard JAR file is a bundle, just not a very useful one. Both Equinox and
        Felix are correct in installing them if told to do so.

        Show
        Richard S. Hall added a comment - A standard JAR file is a bundle, just not a very useful one. Both Equinox and Felix are correct in installing them if told to do so.
        Hide
        Harald Wellmann added a comment -

        I disagree. See OSGi 4.2 Core Spec, section 3.2.1.16:

        The Bundle-SymbolicName header specifies a non-localizable name for this
        bundle. [...] This header must be set.

        So a JAR without this header is not a valid bundle. Is there any other section
        of the spec explicitly supporting plain old JARs?

        Show
        Harald Wellmann added a comment - I disagree. See OSGi 4.2 Core Spec, section 3.2.1.16: The Bundle-SymbolicName header specifies a non-localizable name for this bundle. [...] This header must be set. So a JAR without this header is not a valid bundle. Is there any other section of the spec explicitly supporting plain old JARs?
        Hide
        Richard S. Hall added a comment -

        That is only relevant for R4 bundles, R3 bundles are not required to have a
        symbolic name. So, yes, this is correct. See 3.11 where is says "Release 3
        bundles must be treated according to the R3 specification." There may be other
        places.

        Show
        Richard S. Hall added a comment - That is only relevant for R4 bundles, R3 bundles are not required to have a symbolic name. So, yes, this is correct. See 3.11 where is says "Release 3 bundles must be treated according to the R3 specification." There may be other places.
        Hide
        Richard S. Hall added a comment -

        I should point out, although the OSGi framework behavior is correct, I agree
        that it probably doesn't make sense to deploy plain JAR files into the framework.

        Show
        Richard S. Hall added a comment - I should point out, although the OSGi framework behavior is correct, I agree that it probably doesn't make sense to deploy plain JAR files into the framework.
        Hide
        Snjezana Sevo-Zenzerovic added a comment -

        FWIW, I think this can be closed as duplicate of 8250 - the intent is to move
        non-OSGi jars to glassfish/lib directory and I am actively working on it...

        Show
        Snjezana Sevo-Zenzerovic added a comment - FWIW, I think this can be closed as duplicate of 8250 - the intent is to move non-OSGi jars to glassfish/lib directory and I am actively working on it...
        Hide
        Richard S. Hall added a comment -

        Marking as a duplicate.

            • This issue has been marked as a duplicate of 8250 ***
        Show
        Richard S. Hall added a comment - Marking as a duplicate. This issue has been marked as a duplicate of 8250 ***

          People

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

            Dates

            • Created:
              Updated:
              Resolved: