Glassfish 3.1.2 “n'a pas Pu résoudre une unité de persistance correspondant à la persistance-contexte-ref-name”

Mon projet a la structure suivante:

EAR (derp.ear)
 |
 |____ derp-ui.war
 |
 |____ busctrl.jar
       |
       |____META-INF
               |
               |
               _______ persistence.xml (persistence name of "DEJPA")

L'persistence.xml fichier:

<?xml version="1.0" encoding="UTF-8" ?>
<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"
    version="2.0" xmlns="http://java.sun.com/xml/ns/persistence">

    <persistence-unit name="DEJPA" transaction-type="JTA">
        <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
        <jta-data-source>jdbc/dejpaDS</jta-data-source>
    </persistence-unit>
</persistence>

Je suis en faisant des références au Contexte de Persistance en tant que tel:

@Named
public class ExampleDao implements ExampleDaoService {

    @PersistenceContext(name="DEJPA")
    protected EntityManager entityManager;
}

Malgré cela, je suis arriver la suite de trace de la pile lorsque vous tentez de déployer mon OREILLE à un Glassfish 3.1.2 domaine:

SEVERE: Exception while preparing the app : Could not resolve a persistence unit corresponding to the persistence-context-ref-name [DEJPA] in the scope of the module called [derp#derp-ui.war]. Please verify your application.
java.lang.RuntimeException: Could not resolve a persistence unit corresponding to the persistence-context-ref-name [DEJPA] in the scope of the module called [derp#derp-ui.war]. Please verify your application.
at com.sun.enterprise.deployment.BundleDescriptor.findReferencedPUViaEMRef(BundleDescriptor.java:694)
at com.sun.enterprise.deployment.BundleDescriptor.findReferencedPUsViaPCRefs(BundleDescriptor.java:682)
at com.sun.enterprise.deployment.WebBundleDescriptor.findReferencedPUs(WebBundleDescriptor.java:1056)
at org.glassfish.persistence.jpa.JPADeployer.createEMFs(JPADeployer.java:186)
at org.glassfish.persistence.jpa.JPADeployer.prepare(JPADeployer.java:168)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:871)
at org.glassfish.javaee.full.deployment.EarDeployer.prepareBundle(EarDeployer.java:290)
at org.glassfish.javaee.full.deployment.EarDeployer.access$200(EarDeployer.java:86)
at org.glassfish.javaee.full.deployment.EarDeployer$1.doBundle(EarDeployer.java:141)
at org.glassfish.javaee.full.deployment.EarDeployer$1.doBundle(EarDeployer.java:138)
at org.glassfish.javaee.full.deployment.EarDeployer.doOnBundles(EarDeployer.java:215)
at org.glassfish.javaee.full.deployment.EarDeployer.doOnAllTypedBundles(EarDeployer.java:224)
at org.glassfish.javaee.full.deployment.EarDeployer.doOnAllBundles(EarDeployer.java:250)
at org.glassfish.javaee.full.deployment.EarDeployer.prepare(EarDeployer.java:138)
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:619)

J'ai décompressé l'OREILLE et vérifié que le fichier est présent à l'emplacement donné.

Veuillez informer - je suis entièrement convaincu par la suggestion faite par le journal que le persistence.xml fichier qui se rapporte à des entités et des DAOs dans mon POT devrait en effet être hébergé dans ma GUERRE.

Si vous essayez d'utiliser un EntityManager dans la GUERRE, oui, vous avez besoin d'un persistence.xml fichier dans la GUERRE. Ne devriez-vous pas daos être plutôt que sur le POT où les entités sont-elles définies?
J'ai injecter Contrôleur Impl des Ejb dans JSF sauvegarde des haricots (de la GUERRE), qui à son tour passer de Domaine Entités par le biais de mon DAOs pour la persistance. L'EntityManager n'est pas utilisé dans la GUERRE, il est utilisé dans le DAO JAR. L'persistence.xml le fichier est hébergé à l'OREILLE de la racine dans le busctrl.jar fichier. Cette config fonctionne dans un autre Serveur d'Application 🙁

InformationsquelleAutor 8bitjunkie | 2013-04-26

2

Si busctrl.jar n'est pas un "déployée" composant (contenant des Ejb), puis de le déplacer dans lib/busctrl.jar dans le fichier EAR, où elle sera visible dans le chemin de classe de la guerre de fichier.

Si elle contient des Ejb, puis un peu de chirurgie doit se produire:
- déplacer les Ejb définitions (implémentations) dans le fichier jar(s) à être placé à la racine du fichier EAR (/busEjb.jar).
- déplacer à distance EJB déclarations dans leur propre fichier JAR pour être placé dans l'OREILLE de la bibliothèque (/lib/busEjbClient.jar).
- déplacer des entités JPA & persistence.xml fichier dans leur propre fichier JAR pour être placé dans l'OREILLE de la bibliothèque (/lib/busModel.jar).
Rien dans mon avis sur le sujet suggère que ce que vous avez fait dans votre post original ne devrait pas travail dans Glassfish, l'application ou d'autres serveurs. Le chargeur de classe de la hiérarchie doit avoir fait l'persistence.xml fichier disponible.

Cela dit, la plupart des discussions ont tendance à adopter les meilleures pratiques en matière de passation de la persistence.xml fichier et les classes d'entités dans une bibliothèque distincte. Je soupçonne que cela a à voir avec la fois la hiérarchie des chargeurs de classe (peut-être pas un problème dans ce cas) et avec la de recherche interne de l'outillage pour localiser le persistence.xml fichier qui sera mis en œuvre par EclipseLink dans ce cas. Cette discussion sur EclipseLink peuvent être pertinents.
- L'busctrl.jar il est hébergé au niveau de la racine de l'OREILLE et contient des EJB implémentations des interfaces de contrôle (également hébergés dans ce bocal). Il y a une autre dépendance (common.jar) qui contient les entités JPA est situé dans le dossier lib, comme l'a suggéré. De même j'ai un svccom.jar situé dans le dossier lib qui contient mon DAOs (Printemps hébergé). La hiérarchie travaille dans Oracle Serveur d'Application WebLogic, donc je suis surpris que je ne peux pas juste de déployer une solution alternative (mieux) serveur d'application!
- Suivi: j'ai placé une copie de l'persistence.xml fichier dans le dossier lib en fonction de la dépendance qui contient les DAOs, et cela a résolu le problème sur Glassfish. Savez-vous si c'est un standard pour la pose d'une OREILLE? Je suis perplexe quant à la façon dont Weblogic COMME il est heureux avec elle encore Glassfish ne pouvez pas voir le persistence.xml fichier situé dans l'OREILLE au niveau du POT.
- Rien de clair à propos de la norme :-). Je vois cela comme une bonne pratique si. Vous pouvez également être en mesure de résoudre en travaillant avec le manifeste du classpath.
- Permettez-moi de reformuler: rien de clair dans la norme qui indiquerait pourquoi vous rencontrez un problème avec Glassfish.
InformationsquelleAutor Richard Sitze

Vous devez vous connecter pour publier un commentaire.