glassfish
  1. glassfish
  2. GLASSFISH-12623

EJB embedded handles libraries incorrectly

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 4.0
    • Component/s: cdi
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

      Description

      Hi. I am trying to use EJB embedded for my tests. The scenario is this:

      • I have a maven project that uses TestNG 5.11 as the testing framework
      • I am using GlassFish 3.1 build 07 for the tests
      • there exists only one EJB in src/main/java
      • there is a single test class in src/test/java that starts the container
        (@BeforeClass), tests the EJB, and stops the container (@AfterClass)

      The test run fails with the following exception:
      Jul 12, 2010 4:57:56 PM com.sun.logging.LogDomains$1 log
      SEVERE: Exception while deploying the app
      java.lang.IllegalArgumentException: Sniffers with type [ejb] and type
      [appclient] should not claim the archive at the same time. Please check the
      packaging of your archive
      [/home/rafal/EclipseWorkspaces/Workspace/test-ejb/gfembed8210337129653331178tmp/applications/classes]

      So, the deployment fails to see that this is an EJB jar. However, I fail to see
      why - I debugged and while the container starts it find modules and libraries,
      and it correctly categorizes the 'classes' module as EJB, and testng-5.11.jar as
      library, as can be seen below:

      Jul 12, 2010 4:57:54 PM com.sun.logging.LogDomains$1 log
      INFO: ... skipping... glassfish-embedded-all-3.1-b07.jar
      Jul 12, 2010 4:57:54 PM com.sun.logging.LogDomains$1 log
      INFO: [DeploymentElement] adding library to ScatteredArchive test-classes
      Jul 12, 2010 4:57:54 PM com.sun.logging.LogDomains$1 log
      INFO: [DeploymentElement] adding library to ScatteredArchive testng-5.11-jdk15.jar
      Jul 12, 2010 4:57:54 PM com.sun.logging.LogDomains$1 log
      INFO: [DeploymentElement] adding EJB module to ScatteredArchive classes

      (this can also be seen when one debugs)

      However, when it deploys, a temp Glassgish directory is created
      (gfembed1341086153509304608tmp or similar), and within it
      'applications/classes', where classes corresponds to my EJB archive I suppose.
      Inside, I can see that not only my classes is there, but also the whole TestNG
      jar is exploded and my classes and TestNG's are mangled together, thrown into
      one bag. The problem is that TestNG contains Main-Class in its MANIFEST.MF file,
      which makes GF confused.

      Question: why are the project classes and dependency jar classes exploded and
      mangled together? I added one more dependency and it is also expanded inside
      classes. I think such EJB with dependencies should be packaged inside a temp EAR
      within its 'lib' directory? I tested what happens if I add another dependency
      that is a EJB jar, but no change. Also, when dependencies are expanded in such a
      way, they can overwrite each others resources. Most of the time this might not
      be a problem, but each CDI bean module is required to have META-INF/beans.xml -
      and now it's starting to get scary...

      Ok, so I added META-INF/ejb-jar.xml to my project so that it is treated
      accordingly - I read somewhere that the sniffers might need that. Now, the test
      run fails again, this time saying that testng-5.11.jar is both an EJB module and
      appclient:

      SEVERE: Exception while deploying the app
      java.lang.IllegalArgumentException: Sniffers with type [ejb] and type
      [appclient] should not claim the archive at the same time. Please check the
      packaging of your archive
      [/home/rafal/EclipseWorkspaces/Workspace/test-ejb/gfembed197260800230718800tmp/applications/testng-5.11-jdk15]

      Note that suddenly the application changed the name from 'classes' to
      'testng-5.11-jdk15'. Again, the same story - the expanded classes have
      META-INF/MANIFEST.MF that comes from TestNG and it has the Main-Class entry.
      Again, the same question - why a library (again, correctly classified as a
      library one step before deployment) is messing the whole deployment, even change
      the name of the whole application?

      Finally, I went to my local maven repo and removed the Main-Class entry from
      TestNG jar. It worked, but the EJB lookup failed as it requires
      'java:global/testng-5.11-jdk15/TestEJB', instead of the correct
      'java:global/classes/TestEJB'. The name of the application seems to be changing
      if I introduce more dependencies, I don't see any rule for that, though. What is
      more, with many dependencies, I noticed that the application name changes from
      run to run, which makes it completely unusable.

      The libraries should not be expanded like they are now as they completely
      confuse GF. Many libraries (like JExcel API, the one that I used here as well to
      test if it only TestNG is expanded, but also many many more) do include the
      Main-Class entry, and going here and there in the repo deleting this is not a
      solution. Libraries also have influence on the name of the whole temporary
      deployed application, which should not be the case.

      I am about to attach the test case. It is a maven 2 application, but it
      shouldn't be a problem as GF 3.1-b07 is itself built using maven.

        Activity

        Hide
        jitu added a comment -

        Marina, do you have any response for the last comment from user ?

        Show
        jitu added a comment - Marina, do you have any response for the last comment from user ?
        Hide
        marina vatkina added a comment -

        EJB embedded container doesn't unpackage anything. If there is only 1 EJB module
        in the classpath (or specified via EJBContainer.MODULES), a ScatteredArchive is
        created with the non-EJB jars/dirs added as refs from whatever location they are
        listed in the classpath.

        I did add a property, "org.glassfish.ejb.embedded.skip-client-modules" that if
        set to true (or "true"), will result in skipping entries with Main-Class in
        manifest file.

        The rest is CDI behavior, and I don't understand what's wrong with the current
        GF behavior.

        Show
        marina vatkina added a comment - EJB embedded container doesn't unpackage anything. If there is only 1 EJB module in the classpath (or specified via EJBContainer.MODULES), a ScatteredArchive is created with the non-EJB jars/dirs added as refs from whatever location they are listed in the classpath. I did add a property, "org.glassfish.ejb.embedded.skip-client-modules" that if set to true (or "true"), will result in skipping entries with Main-Class in manifest file. The rest is CDI behavior, and I don't understand what's wrong with the current GF behavior.
        Hide
        jitu added a comment -

        will target for 3.2

        Show
        jitu added a comment - will target for 3.2
        Hide
        jitu added a comment -

        Excluding for 3.1

        Show
        jitu added a comment - Excluding for 3.1
        Hide
        tlcksnyder added a comment -

        I know this bug has not been touched in a while, but the provided test.zip builds and runs cleanly.
        Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0.

        Show
        tlcksnyder added a comment - I know this bug has not been touched in a while, but the provided test.zip builds and runs cleanly. Results : Tests run: 1, Failures: 0, Errors: 0, Skipped: 0.

          People

          • Assignee:
            jjsnyder83
            Reporter:
            szczyp
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: