Arquillian Intégration avec WildFly 10

Question

Quelqu'un peut-il me guider sur comment utiliser Arquillian avec WildFly 10. J'ai récemment migré mon application de JBoss 7 à WildFly 10. Arquillian travaillait avec JBoss 7, mais la même configuration ne fonctionne pas sur wildfly 10.

Je suis en mesure d'intégrer maintenant, mais mes EJBs avec des noms JNDI comme "java: global/xyz/xyzEMFactor" échoue avec l'erreur suivante:

Caused by: java.lang.Exception: {"WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.test.test.env.\"com.xyz.abc.poc.knowledge_ba‌​se.ontology.DBContex‌​tBean\".emFactory is missing [jboss.naming.context.java.global.xyz_dal.xyzpEMFactory‌​]"]} at org.jboss.as.controller.client.helpers.standalone.impl.Serve‌​rDeploymentPlanResul‌​tFuture.getActionRes‌​ult(ServerDeployment‌​PlanResultFuture.jav‌​a:134)

suite est ma classe:

@AccessTimeout(5 * 60 * 60 * 1000) 
@StatefulTimeout(-1) 
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) 
public class DBContextBean<T> { 
    @Inject 
    @EJB(lookup = "java:global/xyz_dal/xyzEMFactory") 
    private xyzEMFactory emFactory; 
} 

Answer 1

Il est parce que, le fichier de guerre testable, je créais un pot comme,

@Deployment(name = "xyz_dal", order = 3) 
public static Archive<?> createDeployment() { 
    JavaArchive jar = ShrinkWrap.create(JavaArchive .class, "xyz_dal.jar") 
      .addClasses(xyzEMFactory.class, DBContextBean.class, xyzDao.class) 
      .addPackages(true, "com.xyz.abc.poc.entities") 
      .addAsResource("test-persistence.xml", "META-INF/persistence.xml") 
      .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml").setManifest(new Asset() { 
       @Override 
       public InputStream openStream() { 
        // dependency management 
        return ManifestBuilder.newInstance() 
          .addManifestHeader("Dependencies", "xyz,javax.api,deployment.abc_common.jar") 
          .openStream(); 
       } 
      }); 
    return jar; 
} 

Il a travaillé quand je l'ai changé pour

@Deployment(name = "xyz_dal", order = 3) 
public static Archive<?> createDeployment() { 
    WebArchive jar = ShrinkWrap.create(WebArchive.class, "xyz_dal.war") 
      .addClasses(xyzpEMFactory.class, DBContextBean.class, xyzDao.class) 
      .addPackages(true, "com.xyz.abc.poc.entities") 
      .addAsResource("test-persistence.xml", "META-INF/persistence.xml") 
      .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml").setManifest(new Asset() { 
       @Override 
       public InputStream openStream() { 
        // dependency management 
        return ManifestBuilder.newInstance() 
          .addManifestHeader("Dependencies", "xyz,javax.api,deployment.abc_common.jar") 
          .openStream(); 
       } 
      }); 
    return jar; 
} 

C'était parce que quand je créais un testable jar, le conteneur enveloppe le jar dans un test.war, et donc le contexte "java: global/xyz/xyzEMFactory" n'était pas disponible.

Answer 2

Je ne sais pas comment cela pourrait fonctionner dans JBoss7 mais: @EJB ou @Inject, je présume @Inject, est superflu. Dans mon expérience, wildfly est parfois plus rigoureux que jboss7 quand on regarde des constructions peu claires.

@Inject 
@EJB(lookup = "java:global/xyz_dal/xyzEMFactory") 
xyzEMFactory emFactory; 

CDI ne peut pas injecter d'ejbs. Ce que nous faisons est parfois:

@Produces 
@EJB(lookup = "java:global/xyz/xyzEMFactory") 
xyzEMFactory emFactory; 

vous pouvez utiliser à d'autres endroits

@Inject 
xyzEMFactory emFactory; 

parce que le haricot injecté ejb peut être utilisée en tant que producteur sur le terrain.