Note à mes collègues en particulier : on en parle après le stand-up ?
Dans notre application cet après-midi j’ai vu un problème de déclaration de propriétés Spring au moment du chargement de mon application. Un fichier de Properties chargé par Spring lors du démarrage par un PropertyPlaceholderConfiguration n’était pas à jour, il me manquait 3 propriétés… soit.
Quelque part, je me demande si le fait de retarder finalement tardivement cette vérification est une si bonne idée. J’ai dû attendre le démarrage de mon application sur Weblogic et ensuite l’exécution de mon premier batch pour le voir…
C’est la vie.
Je n’ai plus qu’à aller m’immoler pour ne pas avoir pensé à mettre à jour mon fichier primeweb.properties…. ou pas.
Que se passerait-il avec un simple EJB ? Que se passerait-il avec du code classique old-school qui serait capable de me dire poliment que 3 propriétés ne sont pas renseignées ? Là pour tout vous dire, j’ai pris une grande exception en pleine face. Je regarderai demain comment au moins mettre un peu de vérification afin de rendre plus polie mon application.
Alors j’ai regardé le fichier application.xml… et il y en a du monde.
Un peu comme un car de supporter de l’OM/du PSG/de l’OL de retour d’un match, c’était un sacré foutoir pour comprendre comment dans ce sac de nœud personne n’avait été blessé jusqu’à maintenant. Il y avait au début du fichier une organisation assez simple avec un DAO, deux Beans déclarés normalement.
Et plus je suis entré dans ce fichier de configuration, plus j’ai eu du mal à comprendre les relations entre Beans… Un peu comme les acteurs d’un sitecom, on ne sait plus très bien qui couche avec qui… Il faut alors configurer votre IDEA (IntelliJ supporte très bien Spring) et il est ensuite tout à fait possible de comprendre les déclarations. Ce n’est pas la faute de Spring, c’est notre faute à nous. On est généreux, nous avons mis un peu tout et n’importe quoi sous la forme de Bean comme un groupe de junkie très excité à l’idée de s’injecter des dépendances…
L’inversion de contrôle est un concept franchement sympa tant qu’on garde le contrôle.
Inversion of Control is a nice concept if you keep some sort of control, copyright nicolas martignole pour la version pour l’export…
A vouloir trop retourner la responsabilité du code, est-ce que finalement nous n’avons pas mis dans un fichier XML un peu trop de choses ? Le prix à payer pour cette flexibilité très pratique lors des tests, est qu’une partie de la vérification qui était effectuée à la compilation, voir au démarrage de l’application, est maintenant pris en charge par Spring. Et ça, ça me dérange. Ce n’est pas la faute de Spring, c’est encore une fois notre faute à nous.
Pour peu que quelqu’un propose un outil, nous sommes tentés de nous en servir et un peu comme un enfant avec un pistolet ou un bouledogue avec un bébé : aie cela fait mal.
Les EJB3 ont un mérite : ils arrivent après la version actuelle de Spring 2.5. Et à ce titre, je commence vraiment à croire que c’est une option très sérieuse qui dans le cadre d’une application de gestion, est tout à fait convenable. J’ai hâte d’acheter et de lire le livre d’Antonio Goncalves du Paris JUG car je pense qu’il y aura du bons sens.
Spring reste un très bon framework qui ne fait pas que de l’IoC (Inversion of Control) mais aussi beaucoup d’autres tâches barbantes. La gestion de la partie JDBC, des templates JMS ou des Transactions : merci ! cela nous évite de devoir gérer une soupe technique peu intéressante.
Cependant pour certains cas (que je devrai préciser si j’étais un gars bien) je continuerai à faire du BoViCoJa (Bon Vieux Code Java) au lieu d’utiliser Spring.
Que l’on ne m’accuse pas de cracher dans la soupe, mais qu’en même temps les gens prennent conscience qu’il ne faut pas tout faire faire par Spring. Il sera parfois plus intéressant de faire du code classique et d’éviter de déclarer une Interface, puis une seule implémentation, pour ensuite l’injecter dans votre code.
Je vous parlerai la prochaine fois de notre copain NoClassDefFoundError et d’AspectJ, le tout mijoté avec du Maven2 et des problèmes de dépendance.
0 no like
Ta réflexion sur le trop d’injection dans tous les sens m’a fait repenser à celle que j’avais en sortant de la présentation de WebBeans à Devoxx. Avec toute cette injection et oujection dans tous les sens, ces annotations qu’on peut définir et hériter entre elle, j’ava
(Désolé du poste coupé, mes dix pouces sur deux mains gauches ont encore frappé…)
Ta réflexion sur le trop d’injection dans tous les sens m’a fait repenser à celle que j’avais en sortant de la présentation de WebBeans à Devoxx. Avec toute cette injection et oujection dans tous les sens, ces annotations qu’on peut définir et hériter entre elle, j’avais l’impression que le lancement des applis allait ressembler à un enfant qui met toutes les pièces de son puzzle dans une boite et secoue très fort en espérant trouver un puzzle fait en relevant le couvercle.
J’aime bien l’image de la boîte de Puzzle !
En exclusivité, le livre qui va bientot révolutionner l’informatique : http://apress.com/book/view/9781430219545
;o)
Ouaih mais mouaih quand même. La remarque est celle de la vraie vie. Ce que je réponds à cela, c’est qu’une équipe qui laisse pourrir un fichier spring, c’est probablement une équipe qui laisse pourrir le code. Une config Spring, ça se conçoit comme toute pièce de code. Et le refactoring, cela s’applique aussi aux fichiers de configuration. Parfois, il y a quand même des tatannes volantes qui se perdent… 🙂