0 Replies Latest reply on Oct 19, 2011 12:21 PM by vineet.reynolds

    Request for comments: EjbArchive vs JavaArchive

    vineet.reynolds

      I'm working on ARQ-593 at the moment, and there are few things that worry me. My experimental work for the bug fix is in one of the branches in my fork. What worries me is that although a ProtocolArchiveProcessor was written to relocate the glassfish-resources.xml, there are cases where @Resource injection would fail in tests.

       

      For instance, if a developer were to

      • create a @Deployment with only EJBs and necessary classes in a JavaArchive
      • add deployment descriptors (like ejb-jar.xml and glassfish-ejb-jar.xml) to the JavaArchive,
      • and map the logical names in the tests to actual resources using the vendor specific descriptors (in glassfish-ejb-jar.xml)

       

      then, resource injection in a JUnit TestCase would fail, as the protocol unit typically tends to be a WAR. The EJB module is packaged within the WAR as a library in WEB-INF\lib, thus causing the container to ignore the resource mappings in the vendor descriptors. Eventually,  a web-module specific deployment descriptor (glassfish-web.xml in this case) with the same mapping is required to make resource injection work.

       

      This is not desirable from the point of view of testing EJBs, as a developer must now know 

      • that Arquillian creates a WAR for deployment that contains the EJB jar
      • and that hand crafting an EnterpriseArchive with a EJB module, is a better choice than a JavaArchive

       

      Considering this,

      • would it be preferable to distinguish between EJB archives and plain JARs? We could create a new EjbArchive class for this purpose. EjbArchives would be added by Arquillian to an EnterpriseArchive instead of a WebArchive for deployment. This would ensure that the container would process the descriptors in the deployment. JavaArchives would continue to be supported to allow developers to add JARs to EARs and WARs. This might also help resolve ARQ-223.
      • If we cannot ensure that JNDI bindings in a testcase are valid, should we look at warning developers when potential scenarios arise? We could parse a deployment and verify the presence of vendor descriptors that might be ignored by the container, because they would eventually be present in the incorrect location.