glassfishplugins
  1. glassfishplugins
  2. GLASSFISHPLUGINS-324

Latest Eclipse Glassfish plugin cannot deploy a webapp with an ejb jar within WEB-INF/lib

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Won't Fix
    • Affects Version/s: current
    • Fix Version/s: None
    • Component/s: deployment, eclipse, ee projects
    • Labels:
      None
    • Environment:

      Windows 7 64bit, JDK 1.6_23, eclipse: Version: Helios Service Release 1 Build id: 20100917-0705, plugin: Oracle GlassFish Server Tools Part of Oracle Enterprise Pack for Eclipse 11.1.1.6.1, 1.6.1.201009290929

      Description

      We have a pretty complex application that we cannot deploy using the glassfish plugin. It composes of multiple modules that we develop, stored within WEB-INF/lib as libraries. Two of these modules is an ejb jar with a few ejbs (one contains SLSBs, and one contains only MDBs) . We use Servlet 3.0 web.xml, and 3.1 ejb-jar.xml. We also use CDI, so we include beans.xml in the ejb jar files.

      After having configured Eclipse, the GF plugin and GF itself, when trying to deploy the application we get the following error message:

      [#|2011-01-05T09:57:10.108+0000|SEVERE|glassfish3.0.1|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=23;_ThreadName=Thread-1;|Exception while loading the app
      java.lang.RuntimeException: Unable to load EJB module. DeploymentContext does not contain any EJB Check archive to ensure correct packaging for C:\Program Files (x86)\glassfishv3\glassfish\domains\domain1\eclipseApps\MpWeb
      at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:133)
      at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:63)
      at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:175)
      at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:216)
      at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:338)
      at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:183)
      at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:272)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
      at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1224)
      at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:365)
      at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:204)
      at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
      at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
      at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)
      at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
      at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
      at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
      at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
      at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
      at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
      at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
      at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
      at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
      at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
      at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
      at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
      at java.lang.Thread.run(Thread.java:662)

      After taking a look around in GF directories, we found a directory called 'eclipseApps'. Within is our application (exploded), and has WB-INF/lib directory with all our jars. All external libraries (around 30) are jar files, as expected. The libraries that we develop (8 modules, 2 ejb modules) are exploded - they are directories that follow the naming patter of a jar file: ModuleName.jar. However, the two directories that stand for our ejb modules have names following a different pattern: ModuleName_jar (note the underscore). I will attach a screenshot that shows this.

      When the application war file is exported using eclipse, all modules are simply jar files and deployment using the GF web console works fine. We don't know whether the eclipse plugin problem is that certain modules are exploded, or that the naming pattern for our ejb modules is different (we suspect the latter).

      Marking as blocker and high priority as this makes development a real nightmare - we can only deploy externally and attach the debugger. We don't get hot deployment this way.

      1. cfish.log
        14 kB
        JFK9
      1. screen.png
        11 kB

        Activity

        Hide
        drivera added a comment -

        This issue also occurs on Linux, using Ubuntu 10.10 32-bit, and is as-yet unfixed.

        Show
        drivera added a comment - This issue also occurs on Linux, using Ubuntu 10.10 32-bit, and is as-yet unfixed.
        Hide
        JFK9 added a comment - - edited

        I have this problem with Eclipse helios and glassfish plugin for glassfish 3.1 under windows server 2008.

        When run outside Eclipse on glassfish the package deploys just fine and I can see it in the console running under the web and ejb containers, and I can see the EJBs as well as the web components.

        When packaging web and ejbs using an ear everything works fine inside eclipse with the plugin.

        The update site you give does not install as it is earlier than that which I have

        Oracle GlassFish Server Tools 1.7.1.201102261603 oracle.eclipse.tools.helios.glassfish.feature.group

        I also tried a simple experiment under Eclipse.
        1/ Create a Dynamic web application with a Servlet which calls an EJB which is defined in the web application projects src folder. This works fine. The Webapp is shown as having ejbs in the glassfish admin console.
        2/ Create an EJB project and add a bean to it. In the original web application reference this project using Properties->Deployment Assembly and add it to the WEB-INF/lib path. Call this EJB "in a different project" from the original Servlet. This fails with a naming exception, and you can see that the bean is not deployed in the glassfish admin console.

        Show
        JFK9 added a comment - - edited I have this problem with Eclipse helios and glassfish plugin for glassfish 3.1 under windows server 2008. When run outside Eclipse on glassfish the package deploys just fine and I can see it in the console running under the web and ejb containers, and I can see the EJBs as well as the web components. When packaging web and ejbs using an ear everything works fine inside eclipse with the plugin. The update site you give does not install as it is earlier than that which I have Oracle GlassFish Server Tools 1.7.1.201102261603 oracle.eclipse.tools.helios.glassfish.feature.group I also tried a simple experiment under Eclipse. 1/ Create a Dynamic web application with a Servlet which calls an EJB which is defined in the web application projects src folder. This works fine. The Webapp is shown as having ejbs in the glassfish admin console. 2/ Create an EJB project and add a bean to it. In the original web application reference this project using Properties->Deployment Assembly and add it to the WEB-INF/lib path. Call this EJB "in a different project" from the original Servlet. This fails with a naming exception, and you can see that the bean is not deployed in the glassfish admin console.
        Hide
        JFK9 added a comment -

        Here is the example projects and log.

        Show
        JFK9 added a comment - Here is the example projects and log.
        Hide
        ludo added a comment -

        you can try a new flag in the
        GF server configuration in Eclipse (open the server properties dialog)
        and check the box called:
        "Use Real Jar Archives for Deployment".

        This bug is not on the eclipse side, but on the GF side filed as
        http://java.net/jira/browse/GLASSFISH-16216

        Closing this one on the plugin side.

        Show
        ludo added a comment - you can try a new flag in the GF server configuration in Eclipse (open the server properties dialog) and check the box called: "Use Real Jar Archives for Deployment". This bug is not on the eclipse side, but on the GF side filed as http://java.net/jira/browse/GLASSFISH-16216 Closing this one on the plugin side.
        Hide
        ludo added a comment -
        Show
        ludo added a comment - fix will be on http://java.net/jira/browse/GLASSFISH-16216 GF side

          People

          • Assignee:
            Unassigned
            Reporter:
            szczyp
          • Votes:
            4 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: