26 mars 2009

spring-test-context, JPA et dbUnit

Sur ma toute belle appli d'en ce moment que j'adore nous gérons la persistence avec JPA. Comme je suis un grand fan de la testabilité par POJOs (ce qui est super original de nos jours), je préconise d'utiliser spring-test-context pour tester la persistence.

Seulement, j'aime bien aussi utiliser dbUnit pour insérer des données de test prévisibles avant mes tests. Et là ça se complique sérieusement, car il faut passer à dbUnit la connexion JDBC associée à la transaction utilisée par l' EntityManager JPA (vous suivez ?)

Le problème, c'est que spring-test-context ne propose par de méthode listener au sein de la transaction (SPR-4365) ; seulement avant ou après. J'ai donc du étendre le "TransactionalTestExecutionListener" pour ajouter dans beforeTestMethod l'injection des données dbUnit.

La mauvaise surprise, c'est qu'en l'absence d'une indication explicite, Spring utilise un DefaultJpaDialect incapable d'identifier la Connection JDBC utilisée, mais ce n'est pas considéré comme un cas d'erreur donc dbUnit ne partage pas la même connexion :'(
Ajoutez à ça une connexion qui est par défaut en autocommit, des tables Oracle AQ$TRUC qui viennent pourrir les données de test et ça vous donne une idée de mes trois derniers jours :-/

Pour résumer, si vous voulez faire comme moi :
  • N'oubliez pas de préciser le jpaVendorAdapter (HibernateJpaVendorAdapter) dans la définition Spring de votre entityManagerFactory
  • Utilisez DataSourceUtils pour récuperer la connexion associée à la transaction JPA en cours
et là, miracle, ça marche enfin :)

Etape suivante : faire un merge à la volée entre les deux persistence.xml qui vont constituer mon contexte JPA (SPR-2598), le permier étant "mutualisé" avec une autre application ... 


22 mars 2009

IE6 à l'abris grace à nos DSI

Les dernières stats d'utilisation des navigateurs web sont sans appel : IE6 décline face à IE7 et Firefox3 qui se partagent le marché en 50/50


Ce qui est intéressant ici c'est l'effet "dent de scie" sur la courbe, qui montre que de très nombreux utilisateurs sont contraints d'utiliser IE6 5 jours par semaine, et passent sous FireFox le week-end. 

Ca ne vous rappelle rien ? Quel est le navigateur "corporate" installé sur vos postes préconfiguré et labellisé par l'entreprise, recommandé par le service technique et nécessaire pour faire marcher correctement vos applications Intranet ?

Autrement dit, les meilleurs clients de IE6 ce sont ... nos DSI, qui continuent à le conserver frileusement (utilisent-ils FF le week-end ?). Malgré toutes les plaintes des développeurs web, ses soucis de performances et tout ce qu'on pourra lui reprocher, IE6 a encore de beaux jours devant lui : avec la crise-qui-fait-peur aucun DSI ne se lancera dans une migration des postes qui ne rapporte rien à court terme. 

Et pourtant, avez-vous estimé le temps perdu à adapter votre appli web pour qu'elle marche sous IE6, alors qu'elle fonctionnait déjà très bien sur à peut près tout le reste ?