当前位置: 首页 > 知识库问答 >
问题:

Glassfish 3.1.2“无法解析与persistence-context-ref-name对应的持久性单元”

方季同
2023-03-14

我的项目具有以下结构:

EAR (derp.ear)
 |
 |____ derp-ui.war
 |
 |____ busctrl.jar
       |
       |____META-INF
               |
               |
               _______ persistence.xml (persistence name of "DEJPA")
<?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> 
@Named
public class ExampleDao implements ExampleDaoService {

    @PersistenceContext(name="DEJPA")
    protected EntityManager entityManager;
}
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)

请告诉我--我完全不相信日志的建议,即与我的JAR中的实体和DAO有关的persistence.xml文件实际上应该托管在我的WAR中。

共有1个答案

陆昕
2023-03-14

如果busctrl.jar不是一个“部署”组件(包含EJB),那么将它移到EAR文件中的lib/busctrl.jar,在war文件的类路径上可以看到它。

如果它确实包含EJB,那么需要进行一些操作:

>

  • 将EJB定义(实现)移动到jar文件中,放在EAR文件的根级别(/busejb.jar)。

    在我对该主题的评论中,没有任何迹象表明您在最初的帖子中所做的不应该在Glassfish或其他应用服务器中工作。类加载器层次结构应该使persistence.xml文件可用。

    也就是说,大多数讨论倾向于将persistence.xml文件和实体类放置到单独的库中的最佳实践。我怀疑这与类加载器层次结构(在本例中可能不是问题)和定位persistence.xml文件的内部搜索工具有关-在本例中,该工具将由EclipseLink实现。关于EclipseLink的讨论可能是相关的。

  •  类似资料:
    • EJB 3.0,EJB 2.0中使用的实体bean在很大程度上被持久性机制所取代。 现在,实体bean是一个简单的POJO,它具有与表的映射。 以下是持久性API中的关键角色 - Entity - 表示数据存储记录的持久对象。 可序列化是件好事。 EntityManager - 持久性接口,用于对持久对象(实体)执行添加/删除/更新/查找等数据操作。 它还有助于使用Query接口执行查询。 Per

    • ConfigEmbeddedWebApplicationContext:上下文初始化过程中遇到异常-取消刷新att empt:org.springframework.beans.factory.beanCreationException:创建类路径资源[org/springframework/boot/autoconfiguration/orm/jpa/hibernatejpaAutoConfig

    • Note 本文档翻译自 http://redis.io/topics/persistence 。 这篇文章提供了 Redis 持久化的技术性描述, 推荐所有 Redis 用户阅读。 要更广泛地了解 Redis 持久化, 以及这种持久化所保证的耐久性(durability), 请参考文章 Redis persistence demystified (中文)。 Redis 持久化 Redis 提供了多

    • 对每一个对象都要执行保存,删除或重关联操作让人感觉有点麻烦,尤其是在处理许多彼此关联的对象的时候。一个常见的例子是父子关系。考虑下面的例子: 如 果一个父子关系中的子对象是值类型(value typed)(例如,地址或字符串的集合)的,他们的生命周期会依赖于父对象,可以享受方便的级联操作(Cascading),不需要额外的动作。父对象 被保存时,这些值类型(value typed)子对象也将被保存

    • 我正在开发Hibernate JPA持久性Web应用程序,我的persistence.xml在src/main/Resources/META-INF/persistence.xml(在war文件中,它在WEB-INF/class/META-INF中)。这一切在本地Tomcat服务器上运行良好,但当放在Openshift JBoss EWS上时,在启动时收到此消息: 坚持不懈xml以 并且有两个持久

    • 我们有一个Spring Boot1.4.1应用程序,当我们创建可运行的jar并尝试运行它时,我们会得到以下堆栈跟踪: 我们也找到了这个问题https://github.com/spring-projects/spring-boot/issues/6635,但根据它,这个问题应该在Spring Boot 1.4.1中修复 注意:我们的模型类中没有注释,我们使用hbm.xml文件进行映射。但是,我们使