问题
I experience a strange Exception which occurs when I try to deploy my Java EE application out of the latest Eclipse version (Helios SR2 with the Glassfish adapter version 1.7.1) to the latest Glassfish (3.1). If I deploy the war file manually to the server via the admin console everything works fine. So there does not seem to by a bug in the application itself or in the Glassfish config:
SCHWERWIEGEND: Could not resolve a persistence unit corresponding to the persistence-context-ref-name [com.sun.ejb.containers.TimerBean/em] in the scope of the module called [MyCMS]. Please verify your application.
java.lang.RuntimeException: Could not resolve a persistence unit corresponding to the persistence-context-ref-name [com.sun.ejb.containers.TimerBean/em] in the scope of the module called [MyCMS]. Please verify your application.
at com.sun.enterprise.deployment.BundleDescriptor.findReferencedPUViaEMRef(BundleDescriptor.java:693)
at com.sun.enterprise.deployment.BundleDescriptor.findReferencedPUsViaPCRefs(BundleDescriptor.java:681)
at com.sun.enterprise.deployment.WebBundleDescriptor.findReferencedPUs(WebBundleDescriptor.java:1056)
at org.glassfish.persistence.jpa.JPADeployer.createEMFs(JPADeployer.java:184)
at org.glassfish.persistence.jpa.JPADeployer.prepare(JPADeployer.java:166)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:870)
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:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:355)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:370)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1067)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:96)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1247)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:465)
at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:222)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:168)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:234)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
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:619)
Does anyone experience similar problems with Eclipse and found a solution yet?
Cheers, Fabian
回答1:
Thank you Ludo for your help! I solved my problem: For some reason the mapping of the eclipse workspace to the glassfist eclipseApp folder wasn't correct. Updating eclipse resulted in the whole Maven Dependency Library being deployed. And since a derby.jar [test] was also deployed to glassfish, I got this strange bug. I can't tell anymore how this all happend and why this was caused by updating eclipse...anyway I solved the issue by adding following row Properties > Deployment Assembly: /target/myapp/WEB-INF/lib -> WEB-INF/lib
回答2:
I was getting this error while porting our application from JBoss 6-M2 to Glassfish 3.1.1. The persistence.xml file was archived in the ear file under the META-INF base directory. JBoss had no issue finding it but Glassfish had scoping issues with this location. The solution was to rebuild the archive such that the persistence.xml would be stored within the specific jar's META-INF directory.
回答3:
Is it a Web application or a Full EAR application? I guess you deployed with exploded directory. There is a new option in the GF server properties dialo deploy archives instead of exploded directory. Can you try it? This would tell if the issue in really on the Eclipse packaging side or not. It seems that maybe a persistence.xml file is not correctly setup or deployed?
You can also check the exploded directory content used by the server in the domain directory. Check for the eclipsApps sub directory.
来源：https://stackoverflow.com/questions/5154828/glassfish-deployment-out-of-eclipse-helios-sr2-fails