users@glassfish.java.net

Re: EntityManager not being injected into abstract EJB?

From: <glassfish_at_javadesktop.org>
Date: Thu, 15 Apr 2010 07:48:47 PDT

> glassfish_at_javadesktop.org wrote:
> Right. But here is the problem: embedded or not, it's
> still should be a JavaEE
> artifact to deploy properly. In a regular server mode
> (i.e. non-embedded), you
> would either package all your parts (minus may be the
> client class) into a
> single EJB module or an ear file if you want to keep
> all parts separate.

Marina, it gets weirder.

I've just completed a whole lot of Maven hacking.

To set the stage:

I have a jenzabar-testing project. This is the actual project that houses our various JUnit test cases that we extend from. One such test case is AbstractEJBTestCase, and it's the actual machine that wraps the EJBContainer. You subclass it like this:
[code]
public class MyTestCase extends AbstractEJBTestCase<SomeBeanInterface, SomeBeanClass> {

  @Test
  public void someTest() throws Exception {
    assertNotNull(this.bean); // this.bean is an instance of SomeBeanInterface
  }

}
[/code]

That's all there is to it. I use the interface type and the class type to find the bean using JNDI global names, and that lets me have a protected bean member variable that is the interface view of the EJB under test.

In that project, under src/main/resources/org/glassfish/embed, I have a domain.xml as extracted from embedded Glassfish, and augmented with the following XML (verbatim):

[code]
    <jdbc-resource pool-name="H2TestPool" jndi-name="${testDatabaseDataSourceName}" />
    <jdbc-connection-pool name="H2TestPool" datasource-classname="org.h2.jdbcx.JdbcDataSource" res-type="javax.sql.DataSource" max-pool-size="1" steady-pool-size="1">
      <property value="${testDatabaseConnectionURL}" name="Url" />
      <property value="${testDatabaseUser}" name="User" />
      <property value="${testDatabasePassword}" name="Password" />
    </jdbc-connection-pool>
[/code]

I've disabled Maven filtering, so what you see here is what ends up in my jenzabar-testing jar, that other projects use in order to subclass AbstractEJBTestCase. The properties like ${testDatabaseConnectionURL} are--in domain.xml syntax--references to system properties that subclasses are obliged to provide. My unit test for jenzabar-testing exercises all this. The data source is installed, and the sample stupid concrete subclass works. It all works fine.

As part of working through all this, I've hacked the "real" project (a business project in our source tree that depends on the jar file that houses this AbstractEJBTestCase) so that all Jenzabar-related dependencies (our in house stuff) are unpacked into the test-classes area. My goal is to make the "real" test as much like the unit-test-that-tests-jenzabar-testing as possible. With me so far? test-classes shows up first in a Maven test run, so what I'm saying is that--just as in the jenzabar-testing unit test--I have [i]everything[/i] available under test-classes. Everything.

Next up, I've deliberately specified that I want EJBContainer to look ONLY at test-classes. I did this with EJBContainer.MODULES.

So then:
* My "real" concrete test case, which extends from my AbstractEJBTestCase, looks only at test-classes for EJB modules.
* Maven is dutifully unpacking all my dependency jars into test-classes using the maven-dependency-plugin's unpack-dependencies goal. This means that I've got my EJBs in there, my entities, etc. etc. etc. It's all just classes. There's effectively nothing else on the classpath. One classpath root that contains absolutely everything.

Guess what. I still get the error.

To be very clear: My runtime classpath is [i]identical[/i] to that of the unit test that is passing (in spirit--i.e. obviously the names of the classes are different, but what I mean is that my test case is there, my entity classes are in there, my bean interface is in there, and my bean class is in there). So, for that matter, is the actual test case class itself, as well as AbstractEJBTestCase.class. I took my classpath and dumped the whole thing (within reason) by value into test-classes.

Could you think of other reasons for this error? I'm beginning to think that this, too, is a red herring.

Best,
Laird
[Message sent by forum member 'ljnelson']

http://forums.java.net/jive/thread.jspa?messageID=397161