glassfish
  1. glassfish
  2. GLASSFISH-17932

Weld throws NoClassDefFoundError at deployment on Web EJBs within EAR Web module

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.2_dev
    • Fix Version/s: 3.1.2_dev
    • Component/s: cdi
    • Labels:
      None
    • Environment:

      Win7 x86

      Description

      Take the small canonical EARs attached. Both contain a client ejb jar, an ejb module, and a web module. The web module contains an EJB (@javax.ejb.Singleton here just to show the difference with @javax.inject.Singleton, but the result will be the same if @Stateless).

      I get during deployment:
      Exception while loading the app : by java.lang.NoClassDefFoundError: com/dummy/web/WebAppEjb
      [...]
      Caused by: javassist.CannotCompileException: by java.lang.NoClassDefFoundError: com/dummy/web/WebAppEjb

      If the same class is declared instead as @javax.inject.Singleton, it deploys correctly (it's no longer an EJB there, just a contextual instance).
      If the same class is declared as @javax.ejb.Stateless, the NCDFE also happens.

      It smells like a ClassLoader issue.

      This issue doesn't exist on GF 3.1.1 (incl Weld 1.1.2)
      This situation existed with earlier (November) GF3.1.2 promoted builds (incl Weld 1.1.3). Also, couldn't that be linked to this other issue?
      http://java.net/jira/browse/GLASSFISH-17192

      1. badejb.log
        7 kB
        fabmars
      2. goodejb.log
        3 kB
        fabmars

        Issue Links

          Activity

          Hide
          fabmars added a comment -

          the related logs

          Show
          fabmars added a comment - the related logs
          Hide
          Sivakumar Thyagarajan added a comment -

          This issue duplicates the scenario described in GLASSFISH-17192

          Show
          Sivakumar Thyagarajan added a comment - This issue duplicates the scenario described in GLASSFISH-17192
          Hide
          Sivakumar Thyagarajan added a comment -

          @fabmar: Yes, your intuition on this scenario duplicating the scenario described in GLASSFISH-17192 was correct. I have put back a fix for this issue in trunk and in the 3.1.2 branch (svn commits 51415 and 51417). I also tested the truc-good.ear and truc-bad.ear against a build having these changes and they deploy fine. So, marking this issue as resolved.

          Show
          Sivakumar Thyagarajan added a comment - @fabmar: Yes, your intuition on this scenario duplicating the scenario described in GLASSFISH-17192 was correct. I have put back a fix for this issue in trunk and in the 3.1.2 branch (svn commits 51415 and 51417). I also tested the truc-good.ear and truc-bad.ear against a build having these changes and they deploy fine. So, marking this issue as resolved.

            People

            • Assignee:
              Sivakumar Thyagarajan
              Reporter:
              fabmars
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: