glassfish
  1. glassfish
  2. GLASSFISH-16250

[embedded] Glassfish 3.1 maven-embedded-glassfish-plugin failure when cdi enabled (beans.xml present): java.lang.ClassNotFoundException: org.apache.tools.ant.Task

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1
    • Fix Version/s: None
    • Component/s: embedded
    • Labels:
      None
    • Environment:

      Description

      From http://java.net/jira/browse/JERSEY-689 and https://issues.jboss.org/browse/WELD-872; I'm not sure if this is a Jersey, Glassfish or Weld issue.

      I'm having problems getting my app to run under Glassfish 3.1 embedded, and have boiled the issue down to a minimal test case involving maven-embedded-glassfish-plugin for glassfish 3.1, jersey 1.5, and cdi (weld). There isn't even any Java code of my own in it, only web.xml, beans.xml and a pom.xml that declares a dependency on jersey-server 1.5. I'm using Jersey 1.5 because I need its improved file upload handling and JSON support.

      When I use it to run an embedded glassfish server, deployment to to the embedded server fails with:

      23/03/2011 6:40:28 PM org.glassfish.deployment.admin.DeployCommand execute
      SEVERE: Exception while loading the app : org/apache/tools/ant/Task
      java.lang.ClassNotFoundException: org.apache.tools.ant.Task
      at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
      ... (elided, see full trace linked below) ...

      at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
      at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1465)
      at org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1368)
      at org.glassfish.weld.BeanDeploymentArchiveImpl.handleEntry(BeanDeploymentArchiveImpl.java:485)
      at org.glassfish.weld.BeanDeploymentArchiveImpl.collectJarInfo(BeanDeploymentArchiveImpl.java:473)
      at org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:420)
      at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:148)
      at org.glassfish.weld.BeanDeploymentArchiveImpl.populate(BeanDeploymentArchiveImpl.java:391)
      at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:148)
      at org.glassfish.weld.BeanDeploymentArchiveImpl.<init>(BeanDeploymentArchiveImpl.java:128)
      at org.glassfish.weld.DeploymentImpl.<init>(DeploymentImpl.java:120)
      at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:334)
      at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99)
      at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186)
      at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:249)
      at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460)
      at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
      at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:370)
      ...

      (full exception and log of test run here: https://github.com/ringerc/scrapcode/blob/master/testcases/javaee/embeddedglassfish-jersey15-testcase/README )

      If I delete beans.xml to disable CDI, the failure goes away. The stack trace passes through weld, providing further evidence that it's somewhere in CDI-land that things are breaking.

      I suspected that the problem might be related to WADL generation, so I set com.sun.jersey.config.feature.DisableWADL to true in the jersey servlet init params. That had no effect.

      Excluding all the dependencies of jersey-server, so only the jersey-server jar its self was present, still triggers the issue. It doesn't seem to be an issue with one of jersey-server's dependencies.

      The ready-to-run testcase is here: https://github.com/ringerc/scrapcode/tree/master/testcases/javaee/embeddedglassfish-jersey15-testcase . Just:

      just:

      git clone git://github.com/ringerc/scrapcode.git
      cd scrapcode/testcases/javaee/embeddedglassfish-jersey15-testcase
      mvn clean install

        Activity

        Hide
        ringerc added a comment -

        Jersey 1.5 is already provided by Glassfish. Specifying it correctly as a provided-scope dependency resolves this issue, as the updated test case shows.

        It's still ... odd ... that the failure only occurs when CDI/weld is enabled, and occurs as a class loader issue. I wonder if it's a symptom of the "Overzealous class scanner" issues that affect Seam: http://seamframework.org/Seam3/CompatibilityHome#H-OverzealousClassScanner

        The fact that GF embedded behaves differently to GF standalone in this situation makes this possibly worth looking at.

        Show
        ringerc added a comment - Jersey 1.5 is already provided by Glassfish. Specifying it correctly as a provided-scope dependency resolves this issue, as the updated test case shows. It's still ... odd ... that the failure only occurs when CDI/weld is enabled, and occurs as a class loader issue. I wonder if it's a symptom of the "Overzealous class scanner" issues that affect Seam: http://seamframework.org/Seam3/CompatibilityHome#H-OverzealousClassScanner The fact that GF embedded behaves differently to GF standalone in this situation makes this possibly worth looking at.
        Hide
        scatari added a comment -

        Can we evaluate this for 3.1.2?

        Show
        scatari added a comment - Can we evaluate this for 3.1.2?

          People

          • Assignee:
            Bhavanishankar
            Reporter:
            ringerc
          • Votes:
            2 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: