Fixation “n'a pas Pu résoudre une unité de persistance...” erreurs lors de la PU est spécifié, trouvé

Je suis en cours d'exécution Glassfish 3.1-INSTANTANÉ à compter d'aujourd'hui (2010-11-12).

Je suis à l'aide de l'embedded EJBContainer.

Sur le chemin de la classe, tel que rapporté par le EJBContainer, j'ai un META-INF/persistence.xml. Ce fichier définit deux unités de persistance: l'un appelé "png" et un autre appelé "cx".

Sortie de débogage montre que Glassfish JPA deployer le trouve, et reconnaît à la fois le cx de PU et de la ngp PU.

La EJBContainer des bombes avec la suite de tout-trop-commune de la JPA erreur:

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)

Je souligne de nouveau que le déploiement dans les journaux d'au moins la deployer des rencontres à la fois les unités de persistance.

La classe qui veut utiliser le "cx" PU contient les habituels standard:

@PersistenceContext(unitName="cx")
private EntityManager em;

L'persistence.xml est présent dans (l'habitude Maven place) target/test-classes/META-INF et ressemble à ceci:

<?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>
        <!-- snip -->
    </persistence-unit>

    <persistence-unit name="ngp" transaction-type="JTA">
        <jta-data-source>java:global/jdbc/H2Test</jta-data-source>
        <!-- snip -->
    </persistence-unit>

</persistence>

Glassfish intégré EJBContainer, tout en faisant son travail, sorties ceci:

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

Dépannage recettes, n'importe qui?

Je dois mentionner que je suis en utilisant JTA--gérée par le conteneur des transactions, tant du PUs. Il me semble que XA serait une exigence ici. Serait le fait que mon test de sources de données ne sont pas XA conformes être la cause de cette erreur?
Mise à jour des sources de données à utiliser XA; aucun effet.
Si les sources de données sont XA ou pas ne devrait pas, du moins pas maintenant (peut-être plus tard, si vous décidez d'utiliser les deux EM en même temps, mais c'est une autre histoire). Ne travailler qu'avec une seule PU?
Oui. Eh bien, il est difficile de dire quelle partie est responsable de cette erreur. J'ai, dans le classpath, un AbstractDAO avec un em qui fait référence à la "ngp" unité de persistance, de sorte que l'unité doit être là pour l'injection. Mais rien dans le cas du test utilise l'entité gestionnaire, et le haricot sous test ne permet pas de s'étendre à partir de AbstractDAO. Cette installation A fonctionné avec une ancienne version de Glassfish incorporé--3.0.1-b02 si ma mémoire est bonne.
Temps, je suppose, de perdre le reste de l'après-midi d'ébullition bas un cas de test et de dépôt de Glassfish bug!

OriginalL'auteur Laird Nelson | 2010-11-12

6

Celui-ci est une combinaison de comportement bizarre et une erreur du pilote.

Tout d'abord, l'erreur du pilote.

Le particulier en cas de test JUnit je regardais était celui d'un collègue, et il a été nommé comme s'il s'agissait d'un EJB lui-même, à la suite de notre internes convention de nommage. C'est probablement un couper-coller de l'erreur sur ce que mon collègue de la partie.

Je le mentionne parce que à chaque fois que j'ai ouvert le fichier j'ai regardé comme si il lui-même été un EJB.

Mais bien sûr, il n'est pas un EJB.

Cependant, mystérieusement, il y a un @PersistenceContext annotation de là, et un EntityManager, qui est inutilisé. Le contexte de persistance est un attribut de--vous l'avez deviné -unitName="cx".

De sorte que le comportement étrange, c'est que quelque part entre l'ancien conteneur d'EJB, qui s'est déroulé ce cas de test bien, et maintenant, le conteneur d'EJB a commencé à la traiter de cette non-EJB, non-special class comme une cible valide pour @PersistenceContext injection. Peut-être de ce test est d'être traité comme un managed bean, mais j'étais sous l'impression que l'on réussit les haricots dans un non-CDI environnement devait être annotées.

De toute façon, une fois que j'ai enlevé cette fausse @PersistenceContext annotation, tout a bien fonctionné.

C'est ce qui explique une grande partie du problème. Cependant, le changement entre GF 3.0.1 et GF 3.1 est en effet bizarre (et il pourrait y avoir un bug quelque part). Est votre archive même CDI activé (a-t-il beans.xml)?
Non, c'est de ne PAS délibérément CDI-permis, comme Glassfish a eu toutes sortes d'horribles problèmes avec le CDI dans le passé.

OriginalL'auteur Laird Nelson
4

Si par erreur vous mettez @PersistenceContext(name="cx") au lieu de @PersistenceContext(unitName="cx"), vous obtenez la même erreur avec tout le reste de travail.

Bienvenue DONC. Pour référence future, vous devriez envisager de donner une image plus détaillée et complète réponse, sinon vous risquez d'obtenir downvoted/flaggged. 🙂 Heureux de codage.
Accordé, la réponse est un peu courte, mais c'était juste la solution pour mon problème.

OriginalL'auteur Tudor
0

J'ai connu le même problème. L'erreur était dans le nom de l'un de mes nombloc
```
unitName="PUname error in one of my classes"
```
OriginalL'auteur Mohannd

Vous devez vous connecter pour publier un commentaire.