glassfish
  1. glassfish
  2. GLASSFISH-18501

EAR deployment fails when OSGi bundle is deployed

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 3.1.2_b23, 3.1.2
    • Fix Version/s: None
    • Component/s: OSGi, OSGi-JavaEE
    • Labels:
      None

      Description

      We have a JEE application packaged and deployed as EAR. Now we started to develop some OSGi EJB Application Bundles. Both will be deployed in the same Glassfish instance.

      The OSGi EJB bundle includes some classes which are packaged in the EAR too. For example the package com.macd.foo is included in the bundle. The package com.macd.bar is not included in the bundle but added to the the Ignore-Package entry of bundles manifest.

      Deploying the EAR fails saying that classes from com.macd.bar package could not be found. But the package com.macd.bar is packaged in the EAR file. If the OSGi bundle is removed deployment of EAR works.

      So my questions are:

      • Why does the OSGi bundle affects deployment of EAR file?
      • How can I deploy OSGi bundles containing classes which are available in the EAR file too?

        Activity

        Hide
        Sanjeeb Sahoo added a comment -

        All packages exported by osgi bundles are visible to non-osgi javaee applications, so they can interfere.

        Without knowing how the manifest of the bundle looks like and without knowing what the bundle actually contains, it is difficult to say what's going wrong. My guess is that the ear is trying to load some classes from the ejb bundle, but since the bundle is not getting resolved, it is failing.

        Show
        Sanjeeb Sahoo added a comment - All packages exported by osgi bundles are visible to non-osgi javaee applications, so they can interfere. Without knowing how the manifest of the bundle looks like and without knowing what the bundle actually contains, it is difficult to say what's going wrong. My guess is that the ear is trying to load some classes from the ejb bundle, but since the bundle is not getting resolved, it is failing.
        Hide
        cplaetzinger added a comment - - edited

        Thanks for first response, Sahoo. If I want to use a package within the EAR file and from other OSGi bundles it should be deployed as OSGi bundle?

        E.g. package com.macd.foo is used by the EAR file and some other OSGi bundles. Thus package com.macd.foo has to be deployed as separate OSGi bundle to be available for the EAR and the other bundles. Is this assumption correct?

        Show
        cplaetzinger added a comment - - edited Thanks for first response, Sahoo. If I want to use a package within the EAR file and from other OSGi bundles it should be deployed as OSGi bundle? E.g. package com.macd.foo is used by the EAR file and some other OSGi bundles. Thus package com.macd.foo has to be deployed as separate OSGi bundle to be available for the EAR and the other bundles. Is this assumption correct?
        Hide
        jthoennes added a comment -

        Actually, the order of deployment matters:

        • If the EAR is deployed first, all is fine.
        • But if the OSGi bundle is deployed first deploying the EAR fails.

        Sahoo, please could you suggest some tracing options besides class-loader tracing using -verbose:class?

        Show
        jthoennes added a comment - Actually, the order of deployment matters: If the EAR is deployed first, all is fine. But if the OSGi bundle is deployed first deploying the EAR fails. Sahoo, please could you suggest some tracing options besides class-loader tracing using -verbose:class?
        Hide
        Sanjeeb Sahoo added a comment -

        jthonennes,

        I hope you know how to connect to the osgi shell. Just in case, you don't know, please look at section #10.4.1 of [1]. You need to set glassfish.osgi.start.level.final=3 in osgi.properties file or domain.xml and then telnet localhost 6666. Check to make sure your osgi bundle is getting resolved. If you are finding it difficult to analyse, then attach the server.log. If you can attach the test applications, even better, but I will let you know if I need them or not only after looking at server.log. But, do mention the manifest.mf of the bundle and jar tf of the ear file contents.

        cplaetzinger:
        OSGi bundles are one level above in the classloader hierarchy, so if com.macd.foo is exported by a bundle then the ear file will always use the package from the bundle. If com.macd.foo is a private package of a bundle then the ear file will use its own version.

        [1] http://glassfish.java.net/public/GF-OSGi-Features.pdf

        Show
        Sanjeeb Sahoo added a comment - jthonennes, I hope you know how to connect to the osgi shell. Just in case, you don't know, please look at section #10.4.1 of [1] . You need to set glassfish.osgi.start.level.final=3 in osgi.properties file or domain.xml and then telnet localhost 6666. Check to make sure your osgi bundle is getting resolved. If you are finding it difficult to analyse, then attach the server.log. If you can attach the test applications, even better, but I will let you know if I need them or not only after looking at server.log. But, do mention the manifest.mf of the bundle and jar tf of the ear file contents. cplaetzinger: OSGi bundles are one level above in the classloader hierarchy, so if com.macd.foo is exported by a bundle then the ear file will always use the package from the bundle. If com.macd.foo is a private package of a bundle then the ear file will use its own version. [1] http://glassfish.java.net/public/GF-OSGi-Features.pdf
        Hide
        jthoennes added a comment -

        Hello Sahoo,

        thanks for your answers. I will check my colleage tomorrow.

        Cheers, Jörg

        Show
        jthoennes added a comment - Hello Sahoo, thanks for your answers. I will check my colleage tomorrow. Cheers, Jörg
        Hide
        TangYong added a comment -

        If having not test bundles(including Manifest.MF,etc), I think that the issue is not determined, and suggest that sahoo closed the issue as not reproduced. In addition, once jthoennes uploads more info and finds the issue can be reproduced, the issue will be reopened.

        Show
        TangYong added a comment - If having not test bundles(including Manifest.MF,etc), I think that the issue is not determined, and suggest that sahoo closed the issue as not reproduced. In addition, once jthoennes uploads more info and finds the issue can be reproduced, the issue will be reopened.

          People

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

            Dates

            • Created:
              Updated: