我在从 OC4J 10.1.2.3 迁移到 10.1.3.1.4 时遇到问题。问题在于具有多个 EJB 的应用程序（都是 2.1，没有 EJB 3.0）。Jdeveloper 将采用默认的 ejb-jar.xml（Jdeveloper 在其独立的 OC4J 实例上运行它所需的文件）并将其打包到每个 EJB JAR 模块中，不管是什么。这导致应用服务器在部署时深入每个 EJB JAR 模块，并找到 N 次相同的 ejb-jar.xml 文件（其中 N = EJB 模块的数量）。这会导致重复的 EJB 引用，并会破坏任何 JNDI 查找，例如：“java:comp/env/ejb/EJBName”。因此，部署具有 3 个 EJB、EJB1、EJB2 和 EJB3 的应用程序会导致应用程序服务器注册 9 个 EJB 而不是 3 个。我需要一种最佳实践方式，但在 10.1.3.4 和 JDeveloper 执行的方式之间，情况相当糟糕...
旁注：如果 Web 应用程序的 JNDI 查找代码被重构为“ejb/EJBName”，它们将起作用。但是，这是不可取的。
您应该查看 Oracle 文档以了解您的情况。Oracle® Containers for J2EE Enterprise JavaBeans Developer's Guide 是一个好的开始 根据 Oracle® Containers for J2EE 服务指南第 2 章：使用 JNDI 当您使用“ejb/EJBName”形式执行“本地”查找时。如果您想使用完整的表单，您必须查看“使用 JNDI”一章的“启用全局 JNDI 查找”部分。
问题是我们的部署配置文件中的多个引用。我们为每个 EJB 创建了一个部署配置文件。这意味着每个 EJB 都有自己的 ejb-jar.xml（该文件包含项目中所有 EJBS 的描述）。因此，每次 JDeveloper 创建一个 EJB 时，它都会在它生成的每个 EJB 中放置一个所有 EJBS 的描述符，从而导致 NxN 数量的引用。因此 Nx(N-1) 个额外的引用。
现在，关键是 Oracle 应用服务器 10.1.2.3.0 及以下版本并不关心这些重复的引用。然而，正如我们所见，10.1.3.1.4 是一个非常不同的版本，并且确实中断了。
我们的解决方法：只有 1 个 EJB 部署配置文件，其中包含所有 EJB 类和它们使用的 POJO。请记住，在每个 EJB 有 1 个 EJB 配置文件之前......所做的一切就是让 Jdeveloper（恕我直言）正确生成有效的 EAR。Jdeveloper 和 Oracle 的应用服务器的垃圾的结合是造成这种情况的原因。