Anatole Tresch a annoncé que la société qui l'emploie et soutien son activité au sein du JSR, Crédit Suisse, ne désire pas soutenir le développer du TCK et de l'implémentation de référence de la spec "java configuration", coupant l'herbe sous le pied à cette proposition.
Faut il pleurer ? Je ne pense pas. Cette spec vise à formaliser une API d'accès à des données de configuration des applications JavaEE, avec évidemment de nombreuses interrogations sur l'impact avec CDI et les diverses specs/frameworks qui proposent déjà ce genre de choses.
Pour ce qui me concerne, une spec limitée à Java EE sur un thème aussi fondamental n'a aucun intérêt. Par ailleurs, comme je l'ai déjà indiqué sur ce blog, la spec se concentre sur l'interaction du code de l'application avec la configuration, et non sur la gestion de la configuration des applications. Choisir de standardiser apache commons-configuration ou spring-truc n'a pas un grand intérêt amha, par contre définir comment déclarer de manière standard la conf de mon appli sur mes instances de production, là j'y vois une valeur ajoutée.
A ce jour, j'utilise tout simplement des System properties, qui suffisent très largement à tout ce dont j'ai besoin. Une petite couche utilitaire pour convertir ou injecter ces données ne serait pas de refus, mais pas indispensable. Les plateformes Cloud fournissent toutes un moyen de définir ces propriétés système pour une application, permettant à l'application d'être vierge au moment de son packaging, et non de se coltiner un N-ième deployment descriptor.
Bref, bye bye Java EE Configuration, tu ne me manquera pas.
Faut il pleurer ? Je ne pense pas. Cette spec vise à formaliser une API d'accès à des données de configuration des applications JavaEE, avec évidemment de nombreuses interrogations sur l'impact avec CDI et les diverses specs/frameworks qui proposent déjà ce genre de choses.
Pour ce qui me concerne, une spec limitée à Java EE sur un thème aussi fondamental n'a aucun intérêt. Par ailleurs, comme je l'ai déjà indiqué sur ce blog, la spec se concentre sur l'interaction du code de l'application avec la configuration, et non sur la gestion de la configuration des applications. Choisir de standardiser apache commons-configuration ou spring-truc n'a pas un grand intérêt amha, par contre définir comment déclarer de manière standard la conf de mon appli sur mes instances de production, là j'y vois une valeur ajoutée.
A ce jour, j'utilise tout simplement des System properties, qui suffisent très largement à tout ce dont j'ai besoin. Une petite couche utilitaire pour convertir ou injecter ces données ne serait pas de refus, mais pas indispensable. Les plateformes Cloud fournissent toutes un moyen de définir ces propriétés système pour une application, permettant à l'application d'être vierge au moment de son packaging, et non de se coltiner un N-ième deployment descriptor.
Bref, bye bye Java EE Configuration, tu ne me manquera pas.
3 commentaires:
je t'invite a regarder typsafe config (une lib java pas scala): https://github.com/typesafehub/config
franchement c'est les properties on steroids...
Comme je l'ai expliqué dans l'article, accéder à la config dans mon code ne me pose aucun problème (ok, y'a moyen de faire des choses plus sympa). Par contre, aucune JSR d'adresse le côté "DevOps" de la chose : comment faire une configurable facilement par un Ops, autrement qu'en dézippant un WAR et en éditant des fichiers XML
Allez je me permet d'insister :)
outre le format que je trouve bien plus simple, la lib permet :
- le cascading de conf a travers l'inclusion de fichiers
- la surcharge de clés spécifiques par des properties system
- l'extraction de valeurs depuis l'environnement.
En gros tu définis ta config de dev et tu l'embarques dans le war. Lorsque tu déploies sur un autre environnement tu peux au choix :
- surcharger les clés qui vont bien avec des properties passées en -Dma.clé.surchargée
- forcer l'utilisation d'un autre fichier de configuration (genre prod.conf) qui commence par inclure le fichier de configuration classique puis surcharge avec des valeurs fixées ou extraites des variables d'environnement.
tu dis dans ton article : "Une petite couche utilitaire pour convertir ou injecter ces données ne serait pas de refus"
bah jette un oeil a config :)
Enregistrer un commentaire