Mi proyecto tiene la siguiente estructura:

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

La persistence.xml archivo:

<?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> 

Estoy haciendo referencias al Contexto de Persistencia como tal:

@Named
public class ExampleDao implements ExampleDaoService {

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

A pesar de esto, me estoy haciendo la siguiente traza de pila cuando se esta tratando de implementar mi OÍDO a un Glassfish 3.1.2 dominio:

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)

He descomprimido el OÍDO y comprobado que el archivo está presente en el lugar.

Por favor avisar – estoy totalmente convencidos por la sugerencia formulada por el registro de la persistence.xml archivo que se refiere a las entidades y DAOs dentro de mi FRASCO debe de hecho ser alojados dentro de mi GUERRA.

  • Si usted está tratando de utilizar un EntityManager dentro de la GUERRA, sí, usted necesita un persistence.xml archivo dentro de la GUERRA. No debería usted daos estar en su lugar en el FRASCO donde las entidades se definen?
  • Me inyecto Controlador Impl Ejb en JSF copia de frijoles (GUERRA), que a su vez pasan de Dominio Entitites a través de mi DAOs para la persistencia. El EntityManager no es usado en la GUERRA, se utiliza en el DAO de la JARRA. El persistence.xml el archivo está alojado en el OÍDO de la raíz en el busctrl.jar archivo. Esta configuración funciona en otro Servidor de Aplicaciones 🙁
InformationsquelleAutor 8bitjunkie | 2013-04-26

1 Comentario

  1. 2

    Si busctrl.jar no es un «desplegado» componente (que contiene los Ejb), a continuación, muévalo a lib/busctrl.jar dentro de la OREJA archivo donde será visible en el classpath de la guerra de archivo.

    Si contiene el Ejb, a continuación, algunos de la cirugía debe ocurrir:

    • mover Ejb definiciones (implementaciones) en la jarra archivo(s) a ser colocados en el nivel raíz de la OREJA de archivo (/busEjb.jar).

    • mover remoto EJB declaraciones en su propio archivo JAR para ser colocado en el OÍDO de la biblioteca (/lib/busEjbClient.jar).

    • mover entidades JPA & persistence.xml archivo en su propio archivo JAR para ser colocado en el OÍDO de la biblioteca (/lib/busModel.jar).


    Nada en mi revisión del tema sugiere que lo que hiciste en tu post original no trabajo en Glassfish u otros servidores de aplicaciones. El cargador de clases de la jerarquía debería haber hecho que el persistence.xml archivo disponible.

    Que dijo, la mayoría de las discusiones tienden hacia la mejor práctica de la colocación de la persistence.xml archivo y clases de entidad en una biblioteca independiente. Sospecho que esto tiene que ver tanto con el cargador de clase de la jerarquía (posiblemente no es un problema en este caso) y con la búsqueda interna de utillaje para localizar el persistence.xml archivo – el cual sería ejecutado por EclipseLink en este caso. Este la discusión sobre EclipseLink puede ser relevante.

    • El busctrl.jar está alojado en el nivel raíz de la OREJA y contiene EJB implementaciones de interfaces de Controlador (también alojado en este tarro). Hay otra dependencia (common.jar), que contiene las entidades JPA – este se encuentra en la carpeta lib como se sugiere. Igualmente tengo un svccom.jar situado en la carpeta lib que contiene mi DAOs (Primavera alojado). La jerarquía trabaja en Oracle WebLogic Application Server, así que estoy sorprendido de que no me acaba de implementar una alternativa (mejor) servidor de aplicaciones!
    • Seguimiento: me colocó una copia de la persistence.xml archivo en la carpeta lib basado en la dependencia que contiene los DAOs y ya esta resuelto el problema en Glassfish. Son conscientes de si se trata de un estándar para la colocación de una OREJA? Estoy confundido en cuanto a cómo Weblogic COMO es feliz con ella pero Glassfish no puede ver el persistence.xml archivo que se encuentra en el nivel de la OREJA de la JARRA.
    • Nada claro acerca de la norma :-). Yo veo esto como una mejor práctica, aunque. Usted también puede ser capaz de resolver por trabajar con el manifiesto de la ruta de clases.
    • Déjenme decirlo en otras palabras: no hay nada claro en la norma, lo que podría indicar que porque usted está teniendo un problema con Glassfish.

Dejar respuesta

Please enter your comment!
Please enter your name here