Tests unitaires:plusieurs façons d'obtenir l'EM

**shogatsu** · 26/11/2010, 21h24

Bonjour,
je vous pose une question car jusqu'à présent dans notre appli J2EE, on obtenait l'entityManager via l'annotation
bien connue : @PersistenceContext

Mes tests unitaires basés sur le ClassPathXmlApplicationContext fonctionnent bien sauf que l'architecte du projet
a du (pour des raisons assez complexes mais justifiées) utiliser une nouvelle annotation pour injecter
l'entityManager

Depuis mes tests unitaires n'arrivent plus à 'autowirer' l'entityManager dans mes classes BUsiness que je cherche
à instancier en tant que Bean pour ensuite tester leur methodes...

Ma question est la suivante, dois je créer une classe abstraite du genre AbstractTestBusiness dans laquelle je recupere
mon entityManager comme avant : je dois alors créer des beans héritant de cette classe et copier dans ces classes toutes
les methodes que je veux tester ou bien dois je continuer d'utiliser la classe AbstractBusiness ( dont héritent toutes
les classes Business du projet) et trouver l'origine de l'erreur ?

Si vous souhaitez plus de detail, je posterai le code de mes classes .. ,-)
Merci d'avance
Stephane

**tchize_** · 27/11/2010, 13h30

Envoyé par shogatsu

a du (pour des raisons assez complexes mais justifiées) utiliser une nouvelle annotation pour injecter

Quelle annotation? Précision.

Modifier la hierarchie des tes objets "juste" pour ajouter des données servant aux tests unitaire est une mauvaise idée, les test unitaires ne doivent pas être invasifs.

**shogatsu** · 28/11/2010, 01h22

Envoyé par tchize_

Quelle annotation? Précision.

Modifier la hierarchie des tes objets "juste" pour ajouter des données servant aux tests unitaire est une mauvaise idée, les test unitaires ne doivent pas être invasifs.

En lieu et place de @PersistenceContext, il utilise @inject (ok je comprend) et une nouvelle : @DataRepository qu'il a créée en tant qu'interface, voici le code pour y voir plus clair :

=================================================

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Classe abstractBusiness dont heritent toutes les classes devant
utiliser l'EM
 
public abstract class AbstractBusiness {
 
    protected final ArianeLogger log = new ArianeLogger(getClass().getName());
 
    /** L'entitymanager. */
    @DataRepository
    @Inject
    //@PersistenceContext(unitName="ariane")
    protected EntityManager entityManager;
 
    /**
     * Constructeur.
     */
    public AbstractBusiness() { }
}

=================================================

=================================================
fichier DataRepository.java :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
@Qualifier
@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER})
@Retention(RetentionPolicy.RUNTIME)
public @interface DataRepository {}

=================================================

Deux autres fichiers ont été créés : DataRepositoryProducer et DataRepositoryProducerLocal

dont voici le code :
=================================================

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
DataRepositoryProducer :
@Stateless
public class DataRepositoryProducer implements DataRepositoryProducerLocal {
 
    private EntityManager entityManager;
 
    @Produces @DataRepository // @ConversationScoped
    public EntityManager getEntityManager() {
        return entityManager;
    }
 
    @PersistenceContext(unitName="ariane")
    public void setEntityManager(EntityManager entityManager) {
        this.entityManager = entityManager;
    }
}

=================================================

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
@Local
public interface DataRepositoryProducerLocal {
 
    public EntityManager getEntityManager();
 
    public void setEntityManager(EntityManager entityManager);
}

=================================================

Le but de ces classes, d'apres mon architecte est de partager l'entityManager entre toutes les classes Business et de propager les transactions entre plusieurs méthodes transactionnelles, le hic c'est que mon environnement de test Spring ne parvient pas à gérer cette annotation...

Merci pour votre intéret à cette question

**tchize_** · 28/11/2010, 08h24

Ce sont des annotations CDI. L'avantage c'est qu'elles sont intégrées avec les système d'EJB et autres conteneurs J2EE standard. Comment sont elles gérées dans l'application? Par spring? Par le conteneur J2EE? Si tu es dans le deuxième cas, pour tes unit test, ajoute WELD et démarre le correctement (voir la doc de WELD), c'est l'implémentation de référence de CDI. Mais peut etre que spring a un support CDI? Voir avec l'architecte qui est chargé, au final, de gérer ces annotations.

**shogatsu** · 28/11/2010, 12h25

Salut !
A priori ces anntations CDI sont gérées par le serveur (glassFish en l'occurrence)
car Spring n'est utilisée que pour les tests ...
Cela dit j'ai trouvé un article évoquant une possible incompatibilité entre glassfish et WELD, nous avons GF 3 datant d'octobre dernier, sans doute devrions nous mettre à jour notre version...
Merci en tout cas et à plus !

**tchize_** · 28/11/2010, 13h17

Envoyé par shogatsu

une possible incompatibilité entre glassfish et WELD,

Ce n'est pas un problème si WELD n'est utilisé que pour les test unitaire (et donc ne se retrouve jamais sur glassfish

)

**shogatsu** · 10/12/2010, 22h30

Salut, pour installer weld, j'ai ajouté cdi-api dans mon pom.xml, fais je bonne route ou pas ?? ce sont des packages jBoss il me semble...

COnnais tu une url sur le web montrant un test unitaire utilisant weld et les cdi annotations ?

Merci d'avance

Shogatsu

**tchize_** · 11/12/2010, 08h12

un exemple de weld en java se

http://docs.jboss.org/weld/reference...numberguess-se

aussi, de mémoire, le package à ajouter à maven était "weld"

**shogatsu** · 11/12/2010, 14h23

Merci tchize, je vais essayer d'adapter ça pour executer une requete vers ma bdd mysql via un entityManager injecté en CDI.
A+

**shogatsu** · 12/12/2010, 18h22

Petit retex de mon travail ce weekend :

j'ai enfin réussi à installer weld via maven

Ce que voulais c'était lancer des tests codés avec weld via la commande 'mvn clean test'...pour l"instant le contexte cdi se lance , démarre glassfish et execute le test.

Il me reste encore à créer un test personnel vers ma bdd mais le plus dur est passé, merci en tout cas et pour ceux qui un jour seraient confrontés à ce genre de problème, voila une URL bien pratique :

http://seamframework.org/Documentati...tForMavenUsers

Par contre il reste important de se tenir au courant des sorties des nouveaux packages weld car cette technologie évolue énormément en ce moment

Bonne fin d'année aux lecteurs/lectrices de ce forum

Shogatsu

**shogatsu** · 05/01/2011, 20h14

Et oui malgré le passage en 2011, mes problemes ne se sont pas envolés, ils ont meme pris racine en fait ...

Alors voila le fond du probleme, les tests unitaires avec weld utilisent une dependance 'arquillian' qui elle ne fonctionne correctement que si la connection internet existe car quand on lance 'mvn test -Pglassfish-embedded' ce petit arquillian tente de se connecter à java.sun.com pour y lire une DTD .... super j'avais vachement besoin de ça .... sans blague mais c de la merde (excusez l'expression mais comment fait on en intranet quand toute connection au net est prohibée ?)

Alors loin de me laisser abattre j'ai cherché des solutions, une me semble intéressante, on y parle de créer un uber jar et d'y placer les DTD dedans ..

Quelqu'un a t il dejà créé un uber jar ? Cela vous semble t il etre une bonne piste ?

Merci d'avance à tous ceux ou celles qui chercheront à me sortir de cette impasse ?

PS : le lien ou l'on parle de l'uber jar : http://java.net/jira/browse/GLASSFISH-11516

**tchize_** · 05/01/2011, 20h52

Bhavanishankar added a comment - 21/Oct/10 08:17 AM
This has been fixed for ms6.

comme le dit le truc, c'est fixé dans la milestone 6. Il faudrait donc essayer de l'utiliser dans ton application pour tes tests.

Et oui, je suis d'accord avec toi, une appli qui pompe les DTD sur le net, c'est pas top, mais ce genre d'erreur de programmation est courant, malheureusement.

PS: normalement tu n'a pas besoin de glassfish pour weld (enfin perso je suis arrivé à le faire tourner sans besoin de glassfish, mais je l'ai pas utilisé beaucouo

)

**shogatsu** · 05/01/2011, 21h14

Envoyé par tchize_

comme le dit le truc, c'est fixé dans la milestone 6. Il faudrait donc essayer de l'utiliser dans ton application pour tes tests.

PS: normalement tu n'a pas besoin de glassfish pour weld (enfin perso je suis arrivé à le faire tourner sans besoin de glassfish, mais je l'ai pas utilisé beaucouo

)

Merci tchize
ça me plairait bien de m'en passer

D'ailleurs dans le tuto que j'avais linké précédemment dans mes messages, plusieurs serveurs peuvent faire office de conteneur, notamment jboss
alors plutot que de lancer mvn test -Pglassfish-embedded je vais utiliser le profil jboss : jbossas

A force, je vais bien trouver la solution

Allez ciao

**shogatsu** · 05/01/2011, 22h22

Je reviens sur le topic car je ne saisis pas comment tu as fait ....
En suivant mon tuto, weld s installe immediatement avec arquillian et celui ci demande obligatoirement un conteneur pour lancer les tests d EJB ce qui est logique ... comment as tu utilisé weld ?

**tchize_** · 05/01/2011, 22h26

comme ça
http://docs.jboss.org/weld/reference...s.html#d0e5344

**shogatsu** · 06/01/2011, 11h19

Envoyé par tchize_

comme ça
http://docs.jboss.org/weld/reference...s.html#d0e5344

Merci pour le lien,

là j'ai installé les packages, créé mes classes, etc ...
weld se plante avec le message d'erreur que voici :

-------------------------------------------------------------------------------
Test set: fr.gouv.defense.sga.defmob.test.metier.WeldTest
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.484 sec <<< FAILURE!
devraitPouvoirSelectionnerEnBase(fr.gouv.defense.sga.defmob.test.metier.WeldTest) Time elapsed: 0.454 sec <<< ERROR!
java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/faces/context/FacesContext
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.jboss.weld.environment.se.discovery.url.WeldSEResourceLoader.classForName(WeldSEResourceLoader.java:44)
at org.jboss.weld.util.ApiAbstraction.classForName(ApiAbstraction.java:105)
at org.jboss.weld.jsf.JsfApiAbstraction.<init>(JsfApiAbstraction.java:43)
at org.jboss.weld.bootstrap.BeanDeployment.<init>(BeanDeployment.java:101)
at org.jboss.weld.bootstrap.WeldBootstrap$DeploymentVisitor.visit(WeldBootstrap.java:185)
at org.jboss.weld.bootstrap.WeldBootstrap$DeploymentVisitor.visit(WeldBootstrap.java:156)
at org.jboss.weld.bootstrap.WeldBootstrap.startContainer(WeldBootstrap.java:287)
at fr.gouv.defense.sga.defmob.test.metier.WeldTest.initialize(WeldTest.java:84)
at fr.gouv.defense.sga.defmob.test.metier.WeldTest.<init>(WeldTest.java:39)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.junit.runners.BlockJUnit4ClassRunner.createTest(BlockJUnit4ClassRunner.java:202)
at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:251)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:248)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)

Perso, je ne vois pas d'où sort cette référence à FacesContext ....

Par curiosité, j'ai overridé la methode Weld.initialize et au lieu d'utiliser Environnement.SE, je demande Environnement.EE, cette erreur disparait alors mais une nouvelle apparait me demandant le package 'SecurityServices'....as tu déjà eu cette erreur ... ?

**tchize_** · 06/01/2011, 11h53

j'ai travaillé (un peu seulement comme j'ai dit) avec le SE. On a arrêté car en SE, impossible d'avoir les Transaction. Y a une classe centrale dans WELD qui détermine tous les service initialisé et en mode SE: pas de transaction service. En mode EE, trop de services qu'on voulait pas et qu'il aurait fallu fournir. Ces service sont disponsible dans les différents modules de weld. (ex: transaction service fourni par soit jboss tx, soit glassfish, etc)

**shogatsu** · 07/01/2011, 08h24

En fait ce n'est pas weld qui deconne, c'est l'api de Sun : javaee version 6.0
D'après ce que j'ai trouvé sur le net, les classes de ce package n'ont pas de bytecode, alors quand weld essaye de trouver la version de JSF presente dans le classpath, il va dans ce package et quand il charge la classe : BOUM !!!

Je dois donc remplacer dans mon pom la reference javaee-api (6.0) par toutes les dependances dont je vais avoir besoin et qui etaient resolues par ce package ......ex : javax.servlet, javax.ejb, quel bordel

**tchize_** · 07/01/2011, 08h25

les conteneur comme jboss, glassfish etc fournissent en général un package équivalent avec implémentation :p, ceci dit, normalement, java-ee-api, tu dois le définir dans ton pom.xml de maven en scope "provided". Il ne sert qu'à la compilation et ne dois pas entrer dans le .War généré!

Tests unitaires:plusieurs façons d'obtenir l'EM

Spring Java

Discussions similaires

Partager

Partager