glassfish
  1. glassfish
  2. GLASSFISH-19068

deploying hybrid osgi app with ejb bundle failed based on recent gf trunk

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0_b54
    • Component/s: deployment, OSGi-JavaEE
    • Labels:
      None
    • Environment:

      1 Windows XP
      2 Maven 3.0.4
      3 JDK 1.6.0_34
      4 GF Trunk 2012/09/11

      Description

      [Problem]
      deploying hybrid osgi app with ejb bundle failed based on recent gf trunk(2012/09/11)

      When using the following command to deploy a hybrid osgi app with ejb bundle, deploying failed.

      > asadmin deploy --type=osgi E:\gfv4\gftrunk\fighterfish\sample\uas\ejbservice2\target\sample.uas.ejbservice2.jar

      [Failed Info]
      1 Cmd's Failed Info

      remote failure: Error occurred during deployment: Exception while preparing the app : Unable to load the EJB module. DeploymentContext does not contain any EJB. Check the archive to ensure correct packaging for E:\gf0911\glassfish3\glassfish\domains\domain1\applications\sample.uas.ejbservice2.
      If you use EJB component annotations to define the EJB, and an ejb or web deployment descriptor is also used, please make sure that the deployment descriptor references a Java EE 5 or higher version schema, and that the metadata-complete attribute is not set to true, so the component annotations can be processed as expected. Please see server.log for more details.

      Command deploy failed.

      2 StackTrace on server.log
      Pl. see attachment(server.log)

      [Deployed Bundle]
      Pl. see attachment(sample.uas.ejbservice2.jar)

        Activity

        Hide
        TangYong added a comment -

        Sahoo Said:

        Hi Tang,

        That looks like a bug in deployment code. I know deployment team was
        making some change to make deployment not about "OSGi" type deployment
        and I suspect this regression has been introduced during that. Could you
        kindly file a bug and assign it to deployment team?

        Hong,
        The issue here is that an OSGi bundle containing EJBs is being deployed
        with --type=osgi option, yet deployment backend is trying to deploy it
        as an "ejb" archive as you can see from the exception stack.

        Show
        TangYong added a comment - Sahoo Said: Hi Tang, That looks like a bug in deployment code. I know deployment team was making some change to make deployment not about "OSGi" type deployment and I suspect this regression has been introduced during that. Could you kindly file a bug and assign it to deployment team? Hong, The issue here is that an OSGi bundle containing EJBs is being deployed with --type=osgi option, yet deployment backend is trying to deploy it as an "ejb" archive as you can see from the exception stack.
        Hide
        TangYong added a comment -

        Hong Said,

        Sahoo: I just tried a simple EJB OSGi jar test case you gave me before
        and I was able to deploy it as an OSGi bundle with --type osgi with no
        issues.

        Tang: If you have a reproducible test case, please file an issue and I
        will take a look to see what I can find..

        Show
        TangYong added a comment - Hong Said, Sahoo: I just tried a simple EJB OSGi jar test case you gave me before and I was able to deploy it as an OSGi bundle with --type osgi with no issues. Tang: If you have a reproducible test case, please file an issue and I will take a look to see what I can find..
        Hide
        TangYong added a comment -

        Sahoo Said,

        > Sahoo: I just tried a simple EJB OSGi jar test case you gave me before
        > > and I was able to deploy it as an OSGi bundle with --type osgi with no
        > > issues.
        Thanks much. Could you please add this to your deployment dev test suite?

        Show
        TangYong added a comment - Sahoo Said, > Sahoo: I just tried a simple EJB OSGi jar test case you gave me before > > and I was able to deploy it as an OSGi bundle with --type osgi with no > > issues. Thanks much. Could you please add this to your deployment dev test suite?
        Hide
        TangYong added a comment - - edited

        I have reprodued the problem on my gf 09/11 built-snapshot and added the bundles resulting in the problem.

        Show
        TangYong added a comment - - edited I have reprodued the problem on my gf 09/11 built-snapshot and added the bundles resulting in the problem.
        Hide
        TangYong added a comment -

        The complete deploying process is as following:

        1 modify the property on config\osgi.properties

        org.glassfish.osgjpa.extension.useHybridPersistenceProviderResolver=true

        2 asadmin start-domain

        3 asadmin start-database

        4 asadmin deploy --type=osgi sample.uas.entities.jar

        5 asadmin deploy --type=osgi sample.uas.api.jar

        6 asadmin deploy --type=osgi sample.uas.ejbservice2.jar

        The 6's deployment will failed.

        Show
        TangYong added a comment - The complete deploying process is as following: 1 modify the property on config\osgi.properties org.glassfish.osgjpa.extension.useHybridPersistenceProviderResolver=true 2 asadmin start-domain 3 asadmin start-database 4 asadmin deploy --type=osgi sample.uas.entities.jar 5 asadmin deploy --type=osgi sample.uas.api.jar 6 asadmin deploy --type=osgi sample.uas.ejbservice2.jar The 6's deployment will failed.
        Hide
        TangYong added a comment -

        I have investigated the problem and the results are as following:

        1 sortedEngineInfos object contained Deploy Info in the following order.

        1) EJB Deploy
        2) OSGi Deploy

        Pl. see com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:427)

        So, EJB Deploying happened before OSGi Deploying.

        2 tracing how to get sortedEngineInfos object

        On setupContainerInfos(handler, sniffers, context), if sniffers contained EJB Sniffer, sortedEngineInfos will container EJB Deploy Info.

        So, continue to trace sniffers object.

        Pl. see com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:373)

        3 tracing how to get sniffers object

        sniffers = getSniffers(handler, sniffers, context);

        So, investigated getSniffers method, and found on getSniffers method, sniffers object was get by snifferManager.getSniffers(context) method.
        Pl. see
        [1] com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:356)
        [2] com.sun.enterprise.v3.server.ApplicationLifecycle.getSniffers(ApplicationLifecycle.java:648)

        4 about snifferManager.getSniffers(context) method

        the method called com.sun.enterprise.v3.server.SnifferManagerImpl.getApplicableSniffers method to get sniffers object, and because regularSniffers collection contained Connector sniffer, EJB sniffer,...OSGi sniffer,.. in such an order. And sample.uas.ejbservice2.jar has javax.ejb.Stateless annotation, so EJB sniffer can match with sniffer search rule on getApplicableSniffers method, and first added into sniffers.

        Pl.see com.sun.enterprise.v3.server.SnifferManagerImpl.getApplicableSniffers(SnifferManagerImpl.java:150)

        So, I think that "--type=osgi" did not take effect on getting sniffers, and wish hong and shoo confirmed what I said.

        Show
        TangYong added a comment - I have investigated the problem and the results are as following: 1 sortedEngineInfos object contained Deploy Info in the following order. 1) EJB Deploy 2) OSGi Deploy Pl. see com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:427) So, EJB Deploying happened before OSGi Deploying. 2 tracing how to get sortedEngineInfos object On setupContainerInfos(handler, sniffers, context), if sniffers contained EJB Sniffer, sortedEngineInfos will container EJB Deploy Info. So, continue to trace sniffers object. Pl. see com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:373) 3 tracing how to get sniffers object sniffers = getSniffers(handler, sniffers, context); So, investigated getSniffers method, and found on getSniffers method, sniffers object was get by snifferManager.getSniffers(context) method. Pl. see [1] com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:356) [2] com.sun.enterprise.v3.server.ApplicationLifecycle.getSniffers(ApplicationLifecycle.java:648) 4 about snifferManager.getSniffers(context) method the method called com.sun.enterprise.v3.server.SnifferManagerImpl.getApplicableSniffers method to get sniffers object, and because regularSniffers collection contained Connector sniffer, EJB sniffer,...OSGi sniffer,.. in such an order. And sample.uas.ejbservice2.jar has javax.ejb.Stateless annotation, so EJB sniffer can match with sniffer search rule on getApplicableSniffers method, and first added into sniffers. Pl.see com.sun.enterprise.v3.server.SnifferManagerImpl.getApplicableSniffers(SnifferManagerImpl.java:150) So, I think that "--type=osgi" did not take effect on getting sniffers, and wish hong and shoo confirmed what I said.
        Hide
        TangYong added a comment -

        In addition, The problem happened on at org.glassfish.ejb.startup.EjbDeployer.prepare(EjbDeployer.java:191), and I found that when executing ApplicationLifecycle.java:828, the return value of deployer.loadMetaData(provide, context) is null, so the problem happened. However, now, I have not know the reason.

        Show
        TangYong added a comment - In addition, The problem happened on at org.glassfish.ejb.startup.EjbDeployer.prepare(EjbDeployer.java:191), and I found that when executing ApplicationLifecycle.java:828, the return value of deployer.loadMetaData(provide, context) is null, so the problem happened. However, now, I have not know the reason.
        Hide
        Hong Zhang added a comment -

        Thanks for attaching the test case and the initial analysis!

        I was able to reproduce the issue and identify the cause and I have a fix in my local workspace now.

        Only OSGi sniffer should be returned back and not the ejb sniffer in sniffer retrieval. Previous changes to clean up special handling for OSGi only takes care of the cases where the Sniffer.handles method is used to retrieve sniffer, but not the part where the sniffers were retrieved through annotation scanning. Updated that code path to take the archive type into consideration as well (so any sniffer type other than OSGi will be filtered out). Will check in the change after running the usual set of the tests.

        Show
        Hong Zhang added a comment - Thanks for attaching the test case and the initial analysis! I was able to reproduce the issue and identify the cause and I have a fix in my local workspace now. Only OSGi sniffer should be returned back and not the ejb sniffer in sniffer retrieval. Previous changes to clean up special handling for OSGi only takes care of the cases where the Sniffer.handles method is used to retrieve sniffer, but not the part where the sniffers were retrieved through annotation scanning. Updated that code path to take the archive type into consideration as well (so any sniffer type other than OSGi will be filtered out). Will check in the change after running the usual set of the tests.
        Hide
        Hong Zhang added a comment -

        Fix checked in, svn 55899.

        Show
        Hong Zhang added a comment - Fix checked in, svn 55899.

          People

          • Assignee:
            Hong Zhang
            Reporter:
            TangYong
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: