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.
