Problems encountered running Weld's tests-arquillian against the hierarchical deployment model in JBAS

[marius.bogoevici]

After moving from the flat deployment model in JBAS to the hierarchical model, a number of tests from tests-arquillian start failing

One example is

org.jboss.weld.tests.interceptors.ejb.EnterpriseBeanInterceptionTest.

In this case, the arquillian deployment has the following structure:

test.ear

+ lib/

+ <generated-name>.jar - contains META-INF/beans.xml and test classes

+ test.war

   +WEB-INF/lib/arquillian-protocol.jar

In this deployment structure, a BDA will be created for the EJB-JAR, but not for test.war. As a result, a BeanManager is not injected in the test class, which ultimately fails with a NPE.

A solution would be to simply add beans.xml to test.war/WEB-INF. I tried changing the deploy() method to:

{code:java}@Deployment
public static Archive<?> deploy() 
{ return ShrinkWrap.create(EnterpriseArchive.class, "test.ear")
  .addModule(
     ShrinkWrap.create(BeanArchive.class)
        .intercept(Goalkeeper.class, Defender.class, Referee.class)
        .addPackage(EnterpriseBeanInterceptionTest.class.getPackage())
     )
  .addModule(ShrinkWrap.create(WebArchive.class, "test.war").addWebResource(EmptyAsset.INSTANCE, "beans.xml"));
}{code}

but this does not seem to work: the generated test.war from within test.ear still does not contain the beans.xml file.

[aslak]

The current ServletProtocolPackager does not look inside the ear to find a war to attach itself to, so your added test.war will be overwritten. Report a jira please..

As a workaround.. you can change the main deployment to be a war and add the ejb-jar as a library.

(not sure if that satisfies the test case tho..)

[marius.bogoevici]

Thanks, Aslak.

I think it would be nice if one could do some customization to test.war - with the end result being a merger of user config and framework-added features, so I'll follow your advice and add a JIRA.

For now, I think that using a war is equally fine - those tests are from the days when JBoss didn't support WAR-packaged EJBs so we had to use EARs.

[marius.bogoevici]

This is now captured here: https://jira.jboss.org/browse/ARQ-307

[dan.j.allen]

I lost quite a bit of time on a similar issue. I was working with a test that produced an EJB JavaArchive containing a META-INF/ejb-jar.xml. For the life of me, I couldn't figure out why the ejb-jar.xml wasn't being picked up. After lots of debugging, I put the pieces together that since Arquillian deploys the JavaArchive as a library in a WebArchive, and that means the ejb-jar.xml needs to be in WEB-INF (a rule in Java EE which I find really annoying, though I know there are reasons).

I contemplated the idea of having Arquillian perform resource relocation. If it encounters either an EJB archive or a bean (CDI) archive, it would relocate the descriptors into the WEB-INF directory of the WebArchive it creates. Here's the logic that could be put into ServletProtocolDeploymentPackager to perform this relocation.

   public static final ArchivePath EJB_JAR_XML_JAR_PATH =
      ArchivePaths.create("META-INF/ejb-jar.xml"); 
   public static final ArchivePath EJB_JAR_XML_WAR_PATH =
      ArchivePaths.create("WEB-INF/beans.xml");
   public static final ArchivePath BEANS_XML_JAR_PATH =
      ArchivePaths.create("META-INF/beans.xml");
   public static final ArchivePath BEANS_XML_WAR_PATH =
      ArchivePaths.create("WEB-INF/beans.xml");

   ...

   private Archive<?> handleArchive(JavaArchive applicationArchive,
      Collection<Archive<?>> auxiliaryArchives, Archive<?> protocol)
   {
      WebArchive war = ShrinkWrap.create(WebArchive.class, "test.war");
      if (applicationArchive.contains(EJB_JAR_XML_JAR_PATH))
      {
         war.add(applicationArchive.get(EJB_JAR_XML_JAR_PATH).getAsset(),
            EJB_JAR_XML_WAR_PATH);
         applicationArchive.delete(EJB_JAR_XML_JAR_PATH);
      }
      
      if (applicationArchive.contains(BEANS_XML_JAR_PATH))
      {
         war.add(applicationArchive.get(BEANS_XML_JAR_PATH).getAsset(),
            BEANS_XML_WAR_PATH);
         applicationArchive.delete(BEANS_XML_JAR_PATH);
      }
      
      war.addLibraries(applicationArchive, protocol);
      war.addLibraries(auxiliaryArchives.toArray(new Archive[0]));
      return war;
   }

Of course, we should not be hardcoding such logic into the packager. But we do want to be able to offer this level of transparency if we are going to be stuffing an EJB JavaArchive into a WebArchive.

Note, this doesn't solve the problem with ears. That's a separate problem.

[dan.j.allen]

In essence, what I'm saying right now is that you can't have a test that produces an EJB archive with an ejb-jar.xml descriptor (or a CDI bean archive) if you are going to run it on a container that uses the servlet protocol. You're test has to produce a web archive in that case (so it can put ejb-jar.xml or beans.xml at the correct path). This seems like a pretty fundamental limitation to address.

[dan.j.allen]

Ah, the bean archive works since the test is put into the bean archive. But that's really just a coincidence.