JEE 7 : à bas les @EJB on passe tout en @Inject ? Composition de services en run et en test d'intégration

Bonjour,

Mon application utilise des EJB 3.2 employés par des annotations @EJB avec un JEE 7.
Mes EJB fonctionnent souvent par composition de service : un EJB A appelle un EJB B, puis celui-ci peut-être un C et D pour réaliser l'ensemble du boulot à accomplir.
J'ai souhaité adjoindre à mon applications des tests d'intégration d'EJB pour l'éprouver sérieusement : j'ai utilisé Arquillian basé sur Glassfish 4 en arquillian-glassfish-embedded-3.1.

Et là, il y a le début d'un schisme.
Le test d'intégration de l'EJB A, TestA, doit invoquer l'EJB A à l'aide d'une annotation @Inject. C'est ce qu'Arquillian réclame.
Si mon EJB A ne fait pas de composition de service (s'il ne cherche pas à se lier à un autre EJB), tout se passe bien.
En revanche, s'il tente de se lier durant les tests à un EJB B, il le fait cette fois par une annotation @EJB (parce que c'est ce qui figure dans le code source du @Stateless), et cela échoue.

J'ai fait de nombreuses tentatives, de toutes les manières possibles, des heures durant. Sans succès. Et s'il existe sur Internet plusieurs exemples de d'invocation d'un unique EJB avec Arquillian, il ne s'en trouve pas avec un EJB qui en invoque lui-même un autre... parce que c'est là que tout casse.

Au delà de ça : c'est l'enfer sur terre.
La complexité de la mise en place du test avec le déploiement qu'il requiert m'empêcherait de le proposer ensuite à quelqu'un d'une manière qu'il puisse vraiment l'utiliser.
L'ensemble devient vraiment difficile à comprendre côté POM, préparation du déploiement Arquillian, environnement Glassfish, etc. Il y a un seuil d'alerte de complexité qui est passé, parce que cela devient fou : il faut savoir tout jeter aux orties pour recommencer bien quand ça devient dzingue-dzingue.


Les questions que je me pose sont :
1) Puis-je abandonner définitivement les directives @EJB présentes dans mes sources pour l'invocation d'EJB et les remplacer toutes par des @Inject sans souffrir d'une dégradation à quelque niveau que ce soit ?
Il ne faudrait pas alors que le système de transaction, de sécurité/authentification, ou quoi que ce soit d'autre se mette à ne plus fonctionner, par exemple.

2) Quelles adaptations dois-je faire au niveau des sources des EJB Bean eux-mêmes pour qu'ils soient proprement déclarés en mode CDI ?

3) Ai-je effectivement une chance qu'alors Arquillian fonctionne en composition de service ? Quelqu'un l'a t-il déjà expérimenté dans ce mode ?

4) Dois-je abandonner la liaison Arquillian-Glassfish au profit d'un mode plus neutre : Weld ? Mais weld lui, n'est-il pas lié à JBoss ? Qu'est-ce qui est vraiment neutre comme solution ?

Merci !

Grunt.