SEVERE: Exception while invoking class org.glassfish.ejb.startup.EjbDeployer prepare method
SEVERE: Exception while invoking class org.glassfish.javaee.full.deployment.EarDeployer prepare method
SEVERE: Exception while preparing the app
SEVERE: Unable to load the EJB module. DeploymentContext does not contain any EJB. Check the archive to ensure correct packaging for D:\Documents\NetBeansProjects\Test\dist\gfdeploy\Test\Test-war_war.
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
org.glassfish.deployment.common.DeploymentException: Unable to load the EJB module. DeploymentContext does not contain any EJB. Check the archive to ensure correct packaging for D:\Documents\NetBeansProjects\Test\dist\gfdeploy\Test\Test-war_war.
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
at org.glassfish.javaee.full.deployment.EarDeployer.prepare(EarDeployer.java:166)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:871)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:410)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:860)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:757)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1056)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:229)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)
Tim Holloway wrote:I don't know that a bigger heap necessarily means a slower garbage collector. YMMV, but last I saw, GCs were being more targeted towards incremental cleanup than the old "freeze-while-I-free-memory" approach.
Too much memory is, quite simply, more memory than you need. If you allocate excess memory and it doesn't get used, you're stealing it from the rest of the system and leaving it idle, which not only reduces what other processes can do, it's a flat waste of the electricity needed to run the memory chips. And/or paging space, depending on your VM configuration.
If you allocate memory and it gets used, but the system will run nearly as efficiently without the extra memory, then you should consider tuning memory settings so that you get the most efficient performance benefits for your JVM while minimizing the impact on the rest of the system.
Jelle Klap wrote:I don't think you'll be wanting to utilize 8 GBs of heap space in your application. Unless you don't mind waiting on the garbage collector.