O mesmo arquivo .war é implantado bem no Glassfish v2.1. Eu não sei a última vez que tentei v3, mas eu estava querendo verificar a funcionalidade hot-deploy, como se diz estar trabalhando no netbeans 6.8 com glassfish v3. Então, eu implantei como de costume e recebo o seguinte erro:
SEVERE: Exception while invoking class org.glassfish.ejb.startup.EjbDeployer load method .... SEVERE: 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:\src\svn\trunk\gui\target\WEBAPP at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:134) at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:64) at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:153) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:220) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:314) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:169) 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:1159) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1218) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1207) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:362) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:201) 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:241) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:789) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:697) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:951) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:166) 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.FixedThreadPool$BasicWorker.doWork(FixedThreadPool.java:431) at com.sun.grizzly.util.FixedThreadPool$BasicWorker.run(FixedThreadPool.java:410) at java.lang.Thread.run(Thread.java:619) Eu não entendo porque está reclamando sobre qualquer coisa relacionada ao EJB, já que este é um arquivo .war. Alguma ideia?
ATUALIZAÇÃO: Eu arquivei um bug com glassfish: https://glassfish.dev.java.net/issues/show_bug.cgi?id=10592 . Ou isso é um bug no glassfish ou, pelo menos, a mensagem de erro não é útil para rastrear o problema.
https://glassfish.dev.java.net/issues/show_bug.cgi?id=10592
Do bug:
Ok, encontrei a causa (muito obrigado por fornecer o caso de teste!):
O EjbSniffer foi recuperado após a varredura do archive: um (ou mais) dos jars da biblioteca empacotados no archive contém EJBs com annotations do componente. Então o container ejb foi solicitado a carregar o módulo mais tarde.
O contêiner ejb não pôde localizar os metadados correspondentes porque o web.xml é a versão 2.4, portanto, o processamento de metadados ignorou o processamento da anotação (apenas processamos annotations para as versões do esquema Java EE 5+).
Depois que eu mudei o web.xml para fazer referência ao esquema 2.5 (você também pode fazer o esquema 3.0): http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd “>
O aplicativo foi implantado com sucesso.
Por favor, dê uma chance e deixe-me saber se funciona para você.
Eu tenho o esquema 3_0 e ainda recebo o erro. O que é mais interessante é que eu tenho duas guerras, uma é o projeto de exemplo do arquétipo de solda e a outra é uma customização disso. A guerra personalizada não funciona.
Eu verifiquei lado a lado, é o mesmo, exceto para mais classs de modelo e mais propriedades em persistence.xml
Alguém que usa as annotations @Stateless no ManagedBeans está relatando um problema semelhante nos Fóruns do java.net .
Eu não sei se isso se aplica a você, mas a solução dada foi:
Vá para o Admin Console, acesse o centro de atualizações e instale o EJB.
Eu mesmo não testei, então não posso confirmar se isso ajudará.
Apenas meus $ 0,02 …
Eu tive o mesmo erro depois que adicionei a biblioteca JaxMe (versão 0.5.2) ao meu aplicativo. Isso causou uma falha de implantação em um dos meus módulos de guerra – o que me deixou confuso, porque eu não fiz nenhuma alteração nesse módulo. A remoção do JaxMe resolveu o problema.