修复“无法解析持久性单元...” PU指定时发现错误

本文介绍了修复“无法解析持久性单元...” PU指定时发现错误的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我今天运行Glassfish 3.1-SNAPSHOT（2010-11-12）。

我使用嵌入式EJBContainer。

在EJBContainer报告的类路径中，我有一个META-INF / persistence.xml。这个文件定义了两个持久化单元：一个叫做ngp，一个叫做cx。

调试输出显示Glassfish JPA部署者发现它， PU和ngp PU。

EJBContainer用以下常见的JPA错误引爆：

  java.lang.RuntimeException：无法解析模块范围内的persistence-context-ref-name [cx]对应的持久性单元，该模块名为[/ Users / ljnelson / Projects /富/目标/测试类/]。请验证您的申请。 
 at com.sun.enterprise.deployment.BundleDescriptor.findReferencedPUViaEMRef（BundleDescriptor.java:693）
 at com.sun.enterprise.deployment.EjbBundleDescriptor.findReferencedPUs（EjbBundleDescriptor.java:910）
在org.glassfish.persistence.jpa.JPADeployer.prepare（JPADeployer.java:140）
在com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule（ApplicationLifecycle.java:869）
。在COM .sun.enterprise.v3.server.ApplicationLifecycle.deploy（ApplicationLifecycle.java:410）
在com.sun.enterprise.v3.server.ApplicationLifecycle.deploy（ApplicationLifecycle.java:240）
。在组织.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy（EmbeddedDeployerImpl.java:193）
在org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy（EmbeddedDeployerImpl.java:142）
在org.glassfish.ejb .embedded.EJBContainerImpl.deploy（EJBContainerImpl.java:135）
 at org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer（EJBContainerProviderImpl.java:132）
 at javax.ejb。 embeddable.EJBContainer.createEJBContainer（EJBContainer.java:127）

我再次强调，部署日志显示至少部署者会遇到两个持久化单元。

想要使用cxPU的类包含通常的样板：

  @PersistenceContext（unitName =cx）
 private EntityManager em;

persistence.xml存在于（通常的Maven地方） target / test-classes / META-INF ，看起来像这样：

 <？xml version = 1.0encoding =UTF-8？> 
< persistence version =2.0xmlns =http://java.sun.com/xml/ns/persistencexmlns：xsi =http://www.w3.org/2001/XMLSchema-实例xsi：schemaLocation =http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd\"> 
 
< persistence-unit name =cxtransaction-type =JTA> 
< jta-data-source> java：global / jdbc / H2Test< / jta-data-source> 
<！ -  snip  - > 
< / persistence-unit> 
 
< persistence-unit name =ngptransaction-type =JTA> 
< jta-data-source> java：global / jdbc / H2Test< / jta-data-source> 
<！ -  snip  - > 
< / persistence-unit> 
 
< /持久性>

Glassfish嵌入式EJBContainer在完成其工作时输出：

  2010年11月12日下午1:24:05 com.sun.logging.LogDomains $ 1 log 
 FINE：有com.sun.enterprise.deployment。 node.PersistenceUnitNode@2026c088 
 2010年11月12日下午1:24:05 com.sun.logging.LogDomains $ 1 log 
 FINER：使用属性名称
 Nov 12，2010 1:24:05 PM com.sun.logging.LogDomains $ 1 log 
 FINER：有值cx 
 2010年11月12日1:24:05 com.sun.logging.LogDomains $ 1 log 
 FINE：在课堂上com.sun.enterprise.deployment.PersistenceUnitDescriptor方法setName与cx 
 ... snip ... 
 2010年11月12日下午1:24:05 com.sun.logging.LogDomains $ 1 log $ b $ ►精细：GOT com.sun.enterprise.deployment.node.PersistenceUnitNode@1648ff68 
 2010年11月12日下午1时24分05秒com.sun.logging.LogDomains $ 1登录
 FINER：属性名
 Nov 12，2010 1:24:05 PM com.sun.logging.LogDomains $ 1 log 
 FINER：With value ngp 
 Nov 12，2010 1:24:05 PM com.sun.logging .LogDomains $ 1 log 
 FINE：在类com.sun.enterprise.deployment.PersistenceUnitDescriptor方法setName中使用ngp

疑难解答食谱，任何人？

解决方案

这是一个奇怪的行为和试点错误的组合。

我所看到的特定的JUnit测试用例是一个同事，它的名字就像是一个EJB本身，遵循我们的内部命名约定。这可能是我的同事的剪切和粘贴错误。

我提到，因为每次打开文件时，我都把它看作是一个EJB。

但它当然不是EJB。
然而，神秘的是，有一个 @PersistenceContext 注释，还有一个 EntityManager ，这是未使用的。持久化上下文有一个属性 - 你猜对了 - unitName =cx。

奇怪的行为是在运行此测试用例的旧EJB容器之间的某处，现在，EJB容器开始将此非EJB非特殊类视为 @PersistenceContext 注射。也许这个测试用例被视为一个托管bean，但我的印象是非CDI环境中的托管bean必须被注释为这样。
不管怎样，一旦我删除了这个伪造的 @PersistenceContext 注解，一切正常。

I'm running Glassfish 3.1-SNAPSHOT as of today (2010-11-12).
I'm using the embedded EJBContainer.
On the classpath, as reported by the EJBContainer, I have a META-INF/persistence.xml. This file defines two persistence units: one called "ngp" and one called "cx".
Debugging output shows that the Glassfish JPA deployer finds it, and recognizes both the cx PU and the ngp PU.
The EJBContainer bombs out with the following all-too-common JPA error:
java.lang.RuntimeException: Could not resolve a persistence unit corresponding to the persistence-context-ref-name [cx] in the scope of the module called [/Users/ljnelson/Projects/foo/target/test-classes/]. Please verify your application. at com.sun.enterprise.deployment.BundleDescriptor.findReferencedPUViaEMRef(BundleDescriptor.java:693) at com.sun.enterprise.deployment.EjbBundleDescriptor.findReferencedPUs(EjbBundleDescriptor.java:910) at org.glassfish.persistence.jpa.JPADeployer.prepare(JPADeployer.java:140) at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:869) 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.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:193) at org.glassfish.kernel.embedded.EmbeddedDeployerImpl.deploy(EmbeddedDeployerImpl.java:142) at org.glassfish.ejb.embedded.EJBContainerImpl.deploy(EJBContainerImpl.java:135) at org.glassfish.ejb.embedded.EJBContainerProviderImpl.createEJBContainer(EJBContainerProviderImpl.java:132) at javax.ejb.embeddable.EJBContainer.createEJBContainer(EJBContainer.java:127)
I stress again that the deployment logs show that at least the deployer encounters both persistence units.
The class that wants to use the "cx" PU contains the usual boilerplate:
@PersistenceContext(unitName="cx") private EntityManager em;
The persistence.xml is present in (the usual Maven place) target/test-classes/META-INF and looks like this:
<?xml version="1.0" encoding="UTF-8"?> <persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"> <persistence-unit name="cx" transaction-type="JTA"> <jta-data-source>java:global/jdbc/H2Test</jta-data-source>  </persistence-unit> <persistence-unit name="ngp" transaction-type="JTA"> <jta-data-source>java:global/jdbc/H2Test</jta-data-source>  </persistence-unit> </persistence>
The Glassfish embedded EJBContainer, while doing its work, outputs this:
Nov 12, 2010 1:24:05 PM com.sun.logging.LogDomains$1 log FINE: Got com.sun.enterprise.deployment.node.PersistenceUnitNode@2026c088 Nov 12, 2010 1:24:05 PM com.sun.logging.LogDomains$1 log FINER: With attribute name Nov 12, 2010 1:24:05 PM com.sun.logging.LogDomains$1 log FINER: With value cx Nov 12, 2010 1:24:05 PM com.sun.logging.LogDomains$1 log FINE: in class com.sun.enterprise.deployment.PersistenceUnitDescriptor method setName with cx ...snip... Nov 12, 2010 1:24:05 PM com.sun.logging.LogDomains$1 log FINE: Got com.sun.enterprise.deployment.node.PersistenceUnitNode@1648ff68 Nov 12, 2010 1:24:05 PM com.sun.logging.LogDomains$1 log FINER: With attribute name Nov 12, 2010 1:24:05 PM com.sun.logging.LogDomains$1 log FINER: With value ngp Nov 12, 2010 1:24:05 PM com.sun.logging.LogDomains$1 log FINE: in class com.sun.enterprise.deployment.PersistenceUnitDescriptor method setName with ngp
Troubleshooting recipes, anyone?
解决方案
This one is a combination of weird behavior and pilot error.
First, the pilot error.
The particular JUnit test case I was looking at was that of a colleague, and it was named as though it were an EJB itself, following our internal naming convention. This is probably a cut and paste error on my colleague's part.
I mention that because every time I opened the file I stared at it as though it itself were an EJB.
But of course it is not an EJB.
However, mysteriously, there is a @PersistenceContext annotation in there, and an EntityManager, which is unused. The persistence context has an attribute of--you guessed it--unitName="cx".
So the strange behavior is that somewhere in between the old EJB container, which ran this test case fine, and now, the EJB container began treating this non-EJB, non-special class as a valid target for @PersistenceContext injection. Perhaps this test case is being treated as a managed bean, but I was under the impression that managed beans in a non-CDI environment had to be annotated as such.
Anyhow, once I removed this spurious @PersistenceContext annotation, everything worked fine.

这篇关于修复“无法解析持久性单元...” PU指定时发现错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！