如何为嵌入式EJB容器定义测试数据源

Question

我试图使用嵌入式EJB容器测试我的EJB.在生产中,我依赖于在应用程序服务器中配置的JTA数据源.但是,在测试期间,我想连接到不同的DB(内存中的Derby).

问题是我无法看到如何告诉EJB容器覆盖生产persistence.xml中定义的JTA数据源(在src/main/resources/META-INF中),并连接到我的内存中的derby DB.JTA数据源在persistence.xml文件中定义,如下所示:

<jta-data-source>jdbc/myDS</jta-data-source>

尝试1:使用测试persistence.xml

我尝试创建一个测试persistence.xml文件(在src/test/resources/META-INF中),该文件定义:

<property name="javax.persistence.jdbc.driver" value="org.apache.derby.jdbc.EmbeddedDriver" />
<property name="javax.persistence.jdbc.url" value="jdbc:derby:memory:myDataBase;create=true;" />
<property name="javax.persistence.jdbc.user" value="sa" />
<property name="javax.persistence.jdbc.password" value="password" /> 

但这是没有意义的,因为当我指定EJB容器使用被测模块时

Map properties = new HashMap();
properties.put(EJBContainer.MODULES, new File[] { new File("target/classes/") });
ec = EJBContainer.createEJBContainer(properties);

容器只使用主persistence.xml文件而不是我的测试文件.

尝试2:将主类和测试类合并为单个爆炸模块

我能看到使这种方法有效的唯一方法是使用这里描述的方法- 将被测模块的类复制到一个单独的位置(例如target/ejb-testing-classes),然后复制测试persistence.xml将文件放在顶部,然后将此新位置指定给EJB容器:

Map properties = new HashMap();
properties.put(EJBContainer.MODULES, new File[] { new File("target/ejb-testing-classes/") });
ec = EJBContainer.createEJBContainer(properties);

但这似乎是不必要的笨拙.如果我试图在容器中部署预先打包的模块(即依赖项),那么将来也可能是一个问题,因为我需要在合并之前爆炸jar.

我的愿望:数据源覆盖EJB容器的属性

我认为可能有其他属性可以传递到EJB容器中,但到目前为止我只能找到适合openEJB或websphere的属性.我使用嵌入式Glassfish来提供我的嵌入式EJB容器,因为它是目标平台.(我现在已经找到了glassfish属性 - 请参阅下面的更新#1)

当然,每个尝试使用嵌入式EJB容器和不同于生产数据库的数据源测试EJB的人都会遇到这个问题.即便是这个人也放弃了这一点并使用了默认的嵌入式数据库,这对我来说不是一个选择.

任何帮助将非常感激.

更新1:我找到了Glassfish EJB容器接受的属性列表,起初看起来我可以使用以下属性

org.glassfish.ejb.embedded.glassfish.configuration.file

在domain.xml中定义数据源并将容器指向它.但是,根据源代码,除非同时设置了installation.root属性,否则将忽略此属性 - 这意味着需要预先安装glassfish才能运行我的测试.这将无法接受地降低我的Maven项目的可移植性.:(

更新2:我为此问题创建了一个JIRA问题,并建议为glassfish EJB容器引入属性,该容器允许配置JTA数据源.

Answer 1

无法使用嵌入的 Glassfish 来完成。

正如我在更新 1 中所述，为了使用数据源配置嵌入式 EJB 容器，您必须：

1. 使用新数据源配置domain.xml 文件
2. 配置嵌入式 EJB 容器以使用现有的 Glassfish AS 安装
3. 配置嵌入式 EJB 容器以使用步骤 1 中的domain.xml 文件。

所以（感谢步骤 2）再见，可移植性。但这是我必须采用的“解决方案”，直到 Glassfish 开发人员满足我通过属性配置数据源的请求（请参阅问题中上面的 JIRA 链接）。