EJB local Explicite non injecté d’Arquillian

J’utilise Arquillian pour tester un bean de session sans état qui possède une interface locale et distante explicite. Mais dans le test, Arquillian n’injecte rien dans un champ ayant le type d’interface locale, mais fonctionne pour l’interface distante.

@Stateless public class TestServiceImpl implements TestServiceLocal, TestServiceRemote { public Ssortingng greet() { return "hallo"; } }

L’interface distante:

 @Remote public interface TestServiceRemote { public Ssortingng greet(); }

L’interface locale:

 @Local public interface TestServiceLocal { public Ssortingng greet(); }

Et voici le test:

 @RunWith(Arquillian.class) public class GenericEntityDaoEjbIntegrationTest { @Deployment public static JavaArchive createTestArchive() throws UnsupportedEncodingException { return ShrinkWrap.create(JavaArchive.class, "test.jar") .addClasses( TestServiceLocal.class, TestServiceRemote.class, TestServiceImpl.class); } @EJB private TestServiceLocal testServiceLocal; @EJB private TestServiceRemote testServiceRemote; //Will Fail @Test public void testTestServiceLocal() { assertNotNull(this.testServiceLocal); } //Success @Test public void testTestServiceRemote() { assertNotNull(this.testServiceRemote); } }

J’utilise arquillian-glassfish-embedded 1.0.0.CR2, glassfish-embedded-all 3.1 et arquillian-junit-container 1.0.0.CR5 La partie pertinente de mon pom est la suivante:

    org.jboss.arquillian.junit arquillian-junit-container 1.0.0.CR5 test   org.jboss.arquillian.container arquillian-container-spi 1.0.0.CR5 test   org.jboss.arquillian.container arquillian-glassfish-embedded-3.1 1.0.0.CR2 test   org.glassfish.extras glassfish-embedded-all 3.1 test

Voici la partie pertinente du fichier journal (il ne contient aucune exception):

 10.04.2012 15:38:16 com.sun.ejb.containers.BaseContainer initializeHome INFO: Portable JNDI names for EJB TestServiceImpl : [java:global/test/TestServiceImpl!de.test.service.TestServiceRemote, java:global/test/TestServiceImpl!de.test.service.TestServiceLocal] 10.04.2012 15:38:16 com.sun.ejb.containers.BaseContainer initializeHome INFO: Glassfish-specific (Non-portable) JNDI names for EJB TestServiceImpl : [de.test.service.TestServiceRemote, de.test.service.TestServiceRemote#de.test.service.TestServiceRemote] 10.04.2012 15:38:16 com.sun.enterprise.web.WebApplication start INFO: WEB0671: Loading application [test] at [/test] 10.04.2012 15:38:16 org.glassfish.deployment.admin.DeployCommand execute INFO: test was successfully deployed in 11.844 milliseconds.

Quelle est mon erreur? De quoi ai-je besoin pour changer également l’obtention d’une instance injectée pour l’interface de parameters régionaux?

Vous pouvez utiliser l’un des éléments suivants:

Ajoutez un fichier beans.xml au déploiement:
```
 return ShrinkWrap.create(JavaArchive.class, "test.jar") .addClasses( TestServiceLocal.class, TestServiceRemote.class, TestServiceImpl.class) .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml"); 
```
Cela active le CDITestEnricher d’Arquillian, qui est beaucoup plus capable que le EJBTestEnricher. Il peut gérer les annotations @Inject (évidemment), mais aussi les annotations @Resource et @EJB (voir la section sur l’injection de ressources dans les spécifications du CDI). Le conteneur traite ensuite les deux champs annotés @EJB de votre instance de classe de test en tant que points d’injection et injecte les dépendances.
Spécifiez la propriété mappedName pour l’annotation @EJB pour le champ avec le nom JNDI portable du bean déployé. Dans votre cas, cela ressemblera à quelque chose comme:
```
 @EJB(mappedName="java:global/test/TestServiceImpl!com.acme.TestServiceLocal") private TestServiceLocal testServiceLocal; 
```
Vous devez vous assurer que le nom JNDI portable est le même que celui généré pour votre déploiement. J’ai simplement spécifié celui qui a été généré pour mon interface “com.acme.TestServiceLocal”.

En plus des réponses, vous devez également vous assurer que le paramètre @Deployment correct est correct. Pour injecter localement, vous devez vous assurer de disposer de @Deployment(testable=true) (notez qu’il s’agit de la valeur par défaut).

De la documentation Aquillian :

Mode In-Container: @Deployment (testable = true)

Comme nous l’avons mentionné ci-dessus, nous devons reconditionner votre @Deployment, en ajoutant des classes de support Arquillian, pour qu’il s’exécute dans un conteneur. Cela nous donne la possibilité de communiquer avec le test, d’enrichir le test et d’exécuter le test à distance. Dans ce mode, le test s’exécute dans le conteneur distant. Arquillian utilise ce mode par défaut.

Voir Complete Protocol Reference pour une vue d’ensemble de la sortie attendue du processus de création de package lorsque vous fournissez un @Deployment.

Mode client: @Deployment (testable = false)

Maintenant, ce mode est la partie facile. Contrairement au mode en conteneur, qui reconditionne et annule l’exécution du test, le mode as-client fonctionne le moins possible. Il ne reconditionne pas votre @Deployment et ne transmet pas l’exécution du test à un serveur distant. Votre scénario de test s’exécute dans votre machine virtuelle Java comme prévu et vous êtes libre de tester le conteneur de l’extérieur, à la vue de vos clients. Arquillian ne fait que contrôler le cycle de vie de votre @ déploiement.

Voici un exemple appelant un servlet en utilisant le mode en tant que client.

Cela n’aide pas les OP (ils avaient les bons réglages) mais j’espère que cela aidera ceux qui arrivent de Google, comme je l’ai fait.

Essayez de changer TestServiceImpl-> TestServiceBean, il semble que glassfish intégré a des exigences spécifiques pour le nom du bean