new Blog( perso );

Je vous présentais hier un petit outil bien fait pour écrire les tests d'API REST. Sur une application qui fait autre chose qu'un hello world, il faut cependant "bouchonner" les resources externes pour rendre ces appels prédictibles et donc reproductibles dans le cadre de tests automatisés.

Une pratique courante de test consiste à utiliser des Mocks, en considérant qu'on veut valider l'utilisation d'un système tiers, pas son implémentation. Dans le cas un peu particulier d'une base de donnée cependant on est confronté à un problème : le SQL

Les accès à la base de donnée sont en effet liés à son interprétation de ces fameuses requêtes, et le seul moyen de s'assurer que leur syntaxe est correcte, correspond au schéma de la base de données, et retourne bien les données attendues, c'est ... de l'exécuter.

Que l'on fasse du JDBC à l'ancienne ou qu'on utilise un outil de requêtage type-name-safe comme jooq le problème reste le même, une requête n'est vraiment fiable que si on a pu la valider sur une base de données réelle. La solution que tout le monde (?) utilise est une base de donnée H2 - base qui tourne en mémoire - ce qui permet de démarrer rapidement et sans complication une base juste pour la durée des tests. Je me suis fait une Rule junit pour monter cette base H2 et appliquer les scripts de création du schéma, qui sont - évidemment - stocké dans mon repo Git avec le code de mon appli (what else ?).
Pour mettre la base dans un état donné et valider le résultat de mes requêtes, à la recherche d'une solution sympa, légère et qui soit un peu plus productive que des fichiers xml DBunit, je suis tombé sur dbassert.

    @Rule
    public InMemoryDataBase dataBase = new InMemoryDataBase();

    @Test
    public void list_items() throws Exception {

        DbAssert db = DbAssert.init("dbassert.yml");
        DbSource h2 = db.source("h2", getClass());
        h2.clean_table("items");
        h2.fixture("items");

        // Proposal returned
        when()
            .get("/items")
        .then()
            .assertThat().body(containsString("Test item"));

    }

Ca reste un chouille verbeux, donc pour faire clair :

le init consiste à configurer DBAssert pour accéder à la base de test. La DBSource sert à définir où trouver les fichier de données - dans le même package que la classe indiquée. On applique ensuite des fixtures, des fichiers yml de données pour la table du nom correspondant. On peut de même comparer l'état de la base après un update.

Quelques points négatifs qui me font penser que c'est un projet encore jeune, ou bien qu'il y a mieux ailleurs :)

• le projet est sous SVN sur google code. Clairement pas adapté pour la contribution a l'aire de GithHub.
• la librairie n'est pas disponible sur maven central. J'ai fait un export des sources dans mon src/test/java, vu qu'il n'y a que quelques classes
• l'API est perfectible. Je voudrais pouvoir initialiser DbAssert via une DataSource - que j'ai préparée par ailleurs dans ma InMemoryDatabase  - plutôt que via un fichier yml
• l'application d'une fixture utilise un INSERT bête et méchant, sans rechercher les données déjà insérée. On doit donc faire un clean_table systématiquement.

    @Test
    public void should_create_user() {
        given()
           .body("{ \"name\": \"nicolas\" }")
        .when()
           .post("/users")
        .then()
           .assertThat().statusCode(CREATED);
    }

Pendant des années j'ai fait la promotion des tests unitaires, expérimenté tout un tas d'outils (c'est le côté rigolo) sans moi même trop me plier à la pratique. Je pouvais prétexter intervenir sur des couches techniques et/ou d'intégration qui sont d'un compliqué ma pauv' dame.

Bref faites ce que je dis, pas ce que je fais.

J'ai utilisé le TDD une fois lorsque j'ai voulu ré-implémenter fonzie proprement (la version initiale étant au mieux un jouet, ce qui n'a pas empêché de le mettre en production, m'enfin). Il faut reconnaître que ça marche du tonnerre si on arrive à se discipliner.

J'arrive après la bataille et je ne vais donc pas vous faire l'apologie des tests unitaires, d'autre l'ont fait et le font encore bien mieux que moi avec nettement plus de crédibilité. Ce que je constate par contre, c'est que c'est une pratique qui a un impact fort sur les choix d'architecture et de frameworks.

Architecture : une grosses appli Java EE de centaines de milliers de lignes, avec toute la bonne volonté du monde ça met vite un temps fou à builder/tester. Je pourrais vous parler de micro-services (un autre jour ?) mais il est évident qu'avec une suite de test qui prend plusieurs minutes et écroule la machine, le développeur ne va pas lancer les tests régulièrement, ni sans doute avant de committer des modifs mineures (sic!) sauf à faire la police dans l'open-space - bonne ambiance garantie.
Ca veut donc dire qu'il faut savoir cibler les tests à l'essentiels, le 100% de couverture qui teste tous les getter/setter (si si, y'en a) n'apporte vraiment que du surpoids au projet.

Frameworks : Je vous parlais hier de fluent-http, et sans surprise ce framework web permet d'écrire des tests très léger et très rapides. Il sait démarrer sur un port libre aléatoire (ce qui permet aux tests de tourner en parallèle), et ce en quelques centaines de millisecondes.

public class MyResourceTest {

    @BeforeClass
    public static void runWebServer() throws Exception {
        WebServer server = new WebServer(routes -> {
            routes.add(MyResource.class);
        }).startOnRandomPort();
    }


    @Test
    public void should_create_user() {
        given()
           .body("{ \"name\": \"nicolas\" }")
        .when()
           .post("/user")
        .then()
           .assertThat().statusCode(CREATED);
        // TODO test database insert was successful
    }
}

Ce tout petit test me permet de tester mon service REST, il manque juste un peu de mocking pour la partie backend. Il est de niveau API, donc orienté fonctionnel, et me permet de jouer avec l'implémentation.

Jouer c'est bien le mot, car avec des tests aussi rapides, on peut activer infinitest.

Infinitest joue les tests à chaque modification de code (compilation si vous utilisez IntelliJ Idea). On va donc tripatouiller le code par petites touches, Cmd+S et hop le test vérifie qu'on a pas tout cassé et/ou qu'on a enfin réussi à implémenter la fonctionnalité attendue.

On est donc dans une logique de type micro-intégration-continue, très très efficace. Evidemment, si vous n'avez pas des tests rapides, ça n'est pas d'un grand intérêt. C'est donc un ensemble complet de pratique, d'outils, et d'architecture auquel il faut s'attaquer, tous d'un même front.

Pour en arriver là sur des projets non triviaux, il faut aussi savoir découper son appli correctement. Mais je vous parlerais de micro-services une autre fois :)

Le Call-for-Papers du BreizhCamp est une appli custom développées au fil du temps libre l'an dernier et un peu rafraichie cette année. J'ai pour ambition d'en faire une appli "as-a-service" pour toutes les conférence qui veulent bien s'en servir (n'est-ce pas un super business model ?)

Pour arriver à ce résultat, un grand coup de ménage s'impose, et c'est donc l'occasion pour toute équipe de dev de critiquer les choix techniques "historiques" et essayer de nouvelles choses.

J'ai été tenté par Spring Boot, pour finalement me tourner vers fluent-http. Plusieurs raisons à cela :

1. fluent-http est un framework tout neuf, c'est donc motivant d'y mettre son nez
2. fluent-http est fait par l'équipe codestory, avec tout plein de Gageot-eries dedans, et donc c'est beaucoup plus sympa de se dire qu'on peut en discuter avec eux autour d'une bière.
3. fluent-http est incroyablement léger et rapide. Cela permet d'écrire des tests unitaires (voir plus loin) efficaces
4. fluent-http nécessite java 8, donc pas d'excuse, il est temps de se mettre aux lambdas et pourquoi par de mettre null hors d'état de nuire à grand coups de Optional.
5. ça nous fera un sujet pour proposer une conférence :)

Si vous ne le saviez pas, cette semaine c'est DevoxxFrance...

Je ne vais pas vous parler des divers talks de la journée, mais d'un événement tout à fait indirect.

Les organisateur de Devoxx on en effet du faire face à de la publicité sauvage, sur le trotroir juste devant le centre de conférence :

• D'un point de vue communication c'est inattaquable et  assez génial, il faut l'avouer
• Du point de vue de DevoxxFrance, c'est une marque de reconnaissance indirecte : se faire ainsi "hacker" pour une campagne de pub, c'est montrer qu'ils sont incontournable.
• Du point de vue du respect de la conférence, c'est nettement plus discutable. DevoxxFrance vie de l'énergie d'une quinzaine de bénévoles, et avec l'aide de sponsors qui payent leur place. Détourner ainsi cette énergie à des fins de promotion pirate est assez lamentable. En écrivant ce billet je me rend compte que je relaie leur message, mais en même temps j'espère vous faire comprendre à qui vous avez affaire. Détourner ainsi, sans contrepartie, les efforts d'une équipe qui se plie en quatre pour faire bouger notre écosystème, c'est minable.

On my previous blog post I explained how to use docker from Jenkins.



I can see some issues with this setup :

1. You have to register the docker image you want to use as a slave in Jenkins global configuration, and rebuild the image when your environment requires some changes. 
2. Dockefile has to define a ssh server, just to act as a jenkins slave, unrelated to your project needs.
3. Docker plugin isn't elastic, even being a "Cloud" Jenkins plugin. It relies on a static docker-enabled host to run containers. I'd like to keep the Cloud principle to get resources as needed.

So, please welcome oki-docki jenkins plugin. This is still an experimental, unreleased, work-in-progress, use-at-your-own-risk plugin, but here's the concept :

You use your SCM to store both project source code, build script and a Dockerfile that describes your build environment. oki docki will use your Dockerfile to build+run a container and execute build script.


Plugin actually

• checks project workspace for a Dockerfile
• computes its hash, to detect changes
• search for an existing docker image to match, build one if required
• run a container, mounting build workspace in container as /var/workspace
• executes build script

You may notice the docker image isn't pushed to a repository. This is intentional. I like the idea I can rebuild my docker image at any time from scratch, not relying on some binary deployed somewhere. Thanks to Docker incremental build, this isn't such time-consuming.


Benefits :

1. no need to setup anything on jenkins, just have docker-enabled slaves. I'm using a "docker" label for this purpose. This one can benefit from jenkins Cloud slave providers.
2. Dockerfile just defines requirements to build your project. All yours to select a specific JDK, system packages or nodejs version. The same Dockerfile can be used by developers to get a ready-to-use development environment.
3. project Dockerfile is stored in SCM, with application code and build scripts, and all is kept in sync without manual steps. You can have a distinct Dockerfile in a branch if needed.

The current implementation is more a Proof-of-concept than a production-ready plugin, but already let you run a build inside Dockerfile. My initial goal was to start the container and then let jenkins run any regular build steps inside, but this require some Jenkins-remoting redirection hack, which development skills I don't have. On the other side, I also think it make sense to define your CI process as a script store in SCM, not relying on a set of build steps configured in jenkins (must admit I like travis-ci approach on this topic).

I plan to demonstrate this at DevoxxFrance during my talk "La révolution Docker" - assuming I don't break my environment in the meantime :)

[04/08/14 14:10:21] [SSH] Opening SSH connection to localhost:49192.
[04/08/14 14:10:21] [SSH] Authentication successful.
[04/08/14 14:10:21] [SSH] Checking java version of java
[04/08/14 14:10:21] [SSH] java -version returned 1.8.0.
[04/08/14 14:10:21] [SSH] Starting sftp client.
[04/08/14 14:10:21] [SSH] Copying latest slave.jar...
[04/08/14 14:10:21] [SSH] Copied 364 754 bytes.
Expanded the channel window size to 4MB
[04/08/14 14:10:21] [SSH] Starting slave process: cd "/tmp" && java  -jar slave.jar
<===[JENKINS REMOTING CAPACITY]===>channel started
Slave.jar version: 2.36
Ceci est un esclave Unix
Evacuated stdout
Slave successfully connected and online

A nouveau cette année, l'équipe maintenant bien rodée du BreizhCamp est à pied d'oeuvre pour préparer la 4ème édition de la conférence connue internationalement (si, si)

Nouveauté majeure cette année, vu que nous ne parvenons pas à trouver des locaux plus vastes pour vous éviter la déception de ne pas obtenir de place, nous avons étalé la conférence sur une demi journée supplémentaire, mercredi après-midi, pour un hacker-space :

• une session devoxx4kids, profitons que les nouveaux rythmes scolaires ne soient pas encore en application, nos gamins peuvent encore profiter de leur mercredi pour ... coder.
• un hackergarten, l'occasion de découvrir un projet open-source et y contribuer avec l'aide d'un de ses principaux committers.
• des ateliers pratiques divers (voir le call-for-papers plus loin)
• des démos, en particulier sur tout ce qui touche au hardware et à l'embarqué. Les objets connectés, l'Internet des objets (IoT), et les wearables seront à l'honneur.

vive Maven.

Arnaud et moi avons aujourd'hui reçu ce courrier :


Bon bref, cette expérience d'édition a été instructive :

• le travail sous Word avec un template barbare est une horreur
• le processus de relecture et de PAO est une horreur
• ça prend un temps fou
• ça rapport très peu par rapport aux heures consacrées

Nous avons donc décidé de diffuser le contenu librement, après conversion au format AsciiDoc. La conversion étant loin d'être parfaire il reste pas mal de couacs, en plus de ceux présents dans le texte lui même, mais globalement, vous pouvez à présent nous lire de manière totalement gratuite et libre (license CC BY-SA).

https://github.com/ndeloof/apache-maven-book

Si vous voulez nous aider à faire vivre ce livre, vos contributions sont les bienvenues. Sinon il finira de mourir tranquillement en attendant que Maven 4.0 voie le jour. Et si vous regrettez l'époque où vous pouviez nous rémunérer pour ce travail (1,23€ par vente, imposable), nous sommes à votre disposition pour une bière ;-)

OAuth

SecureSocial

Olivier Croisier a publié un article sur ses expérimentations avec Java 8, plus précisément l'introduction des default methods dans les interfaces. Cette nouveauté dans la syntaxe Java a été introduite initialement pour permettre à l'API Collections d'évoluer sans nécessiter à tout un écosystème de librairie de produire de nouvelles versions mises à jour pour Java 8, autrement dit d'attendre 2020 pour que ce soit utilisable concrètement.

Comme l'a très bien analysé Olivier, ces default methods apportent à Java le concept de trait très utilisé en Scala. La tournure fonctionnelle que Java 8 va permettre de faire prendre au langage est un pas majeur, bien plus important amha que l'introduction des génériques en Java 5.

Pour rebondir sur le problème du diamant exposé par Olivier, mon interrogation sur les conflits de méthodes introduites pas les default methods se pose un peu différemment :

nous avons donc une classe Clazz qui implémente deux interfaces Foo et Bar.

1 public interface Foo {
2     public default void helloWorld() {
3         System.out.println("Hello World");}
4 }

1 public interface Bar {
2 }

1 public class Clazz implements Foo, Bar {
2 
3     public static void main(String args[]) throws Exception {
4         new Main().helloWorld();
5     }
6 }

Disons que la première déclare une default method helloworld(). Si Bar définit lui aussi la même default method le compilateur détecte le conflit. Supposons cependant que dans un premier temps Bar n'a pas de telle méthode et que nous compilons notre projet. Nous ajoutons alors a Bar la default method conflictuelle, et re-compilons la classe Bar (et elle seule).

Question : est-ce que notre programme continue de fonctionner comme avant - en gros, est-ce que le bytecode produit fait directement référence à la méthode Foo.helloworld(). Ce qui veut dire que nous ne pouvons plus le re-compiler depuis les sources. Une bonne raison de configurer votre intégration continue avec un "mvn clean install" :)

Je vous laisse essayer par vous même pour avoir la réponse :-D

Java 8 apporte des changements profonds, et expérimenter est la seule façon concrète de comprendre leur impact. Voir ce que fait Yan sur https://github.com/ybonnel/Jdk8Experiments par exemple, je vous encourage à en faire autant.

Je suis en ce moment (exactement en ce moment, dans le TGV Rennes-Paris, connecté en tethering) en train de lire le livre "Functional Programming for Java Developers". Si le livre n'est pas tout juste sorti des presses et ne parle donc qu'à peine de Java 8, et avec une syntaxe obsolète, les concepts fondamentaux sont bien présents et très utiles.


J'entend beaucoup de monde me dire qu'ils n'utiliseront pas Java 8 avant une décennie, bloqués par les contraintes client d'un runtime websphere 6. C'est évidement une réalité, et clairement vous n'aurez pas de traits dans vos applications. Ca n'empêche pas de commence à appréhender les concepts fonctionnels, qui sont un excellent complément à l'approche objet.

En dehors de l'approche fonctionnel que va (mieux) permettre Java 8, ces changements annoncent aussi des bouleversements dans l'écosystème des librairies et frameworks. Exemple type, de nombres frameworks définissent des classes abstraites, que votre code doit étendre. Un jeu d'interface serait plus propre, mais alors impossible de faire évoluer les API. Jenkins par exemple comporte une quantité phénoménale de classes abstraites pour cette raison.

Autre approche si on aime pas les classes abstraites, faire à la façon d'Eclipse, en définissant des interfaces HelloWorld1, HelloWorld2, HelloWorld3, et en testant au runtime quelle interface est implémentée, bref une solution pire que le mal lui même.

Bref, tous les frameworks pre-java 8 - en dehors d'Eclipse - se basent sur des classes abstraites, et pourrissent nos arbres d'héritage. Une opportunité apparaît donc avec Java 8 pour une nouvelle génération de frameworks, basés sur des traits. Le même genre de changement qui a laissé commons-collections sur le carreau avec l'arrivée des génériques et une mise à niveau jamais aboutie, qui a laissé la place à Guava et quelques autres.

Donc, oui, votre client a du Java 5 en production. Oui, c'est une version "End of Life" mais il s'en fout, et vous n'y pouvez rien. Et pourtant, si vous ne voulez pas passer pour un développeur avec des faux airs de Cobol dans quelques années, il est temps pour vous de regarder ce qu'apporte Java 8, d'expérimenter, de découvrir les bénéfices et les concepts de la programmation fonctionnelle, et de pleurer en revenant à votre code sans lambdas ;)

Même si on atteint pas la prolifération de S*UG (Scala | Scrum | Spring | ... | user-groups) qu'offre la capitale, Rennes n'est pas en reste d'activité communautaire. Il y a bien sur le BreizhJUG, devenu au fil du temps une institution locale, mais aussi de plus petit groupes plein de bonnes idées, comme par exemple Rennes Devops.

Avec la possible venue d'OVH dans la capitale Bretonne, le groupe veut démontrer son dynamisme, et organise le 25 janvier un BootCamp DevOps à la Cantine Numérique Rennaise.


Pour ma part, j'ai proposé d'y parler un peu de déploiement continu avec Jenkins, mais surtout de Docker. Donc si vous voulez passer un bon moment et élargir un peu vos horizon d'architecte Java EE, bloquez votre agenda !

Interview de Nicolas Ledez, initiateur du BootCamp :

À l'origine, c'était une idée de Frédéric Alix (http://blog.fredalix.com). Qui pour différentes raisons n'a pas pu y donner suite. Et finalement, pour les développeurs, il y a l'excellent Breizhcamp, mais rien pour les ops - donc… Et j'ai aussi un petit coté maso :p

Hou là !!! Oui beaucoup. Je vais démarrer des cours pour débutant de développement Web dans le cadre du http://labfab.fr/ + Breizhcamp, Devcamp, et plein d'autre trucs  ok, rendez vous le 25 pour te voir à l'oeuvre

infos et inscriptions : http://rennesdevops.fr/bootcamp-rennes-devops/

Devoxx France a ouvert son Call for Paper début décembre, et se pose pour moi la question de quoi proposer.

L'an dernier j'ai mis tout ce que j'avais en magasin, au risque de passer pour un spam-bot. J'ai constaté que les sujets "cloud" ou "continuous delivery" qui me sont chers ne font pas rêver le comité de sélection - ou alors je ne suis pas bon vendeur.

Bref, suivant une suggestion de Nico Martignole, je lance un Google Moderator :

Quel sujet voudriez-vous me voir présenter à Devoxx 2014

A vous de jouer !

J'enchaine les coups de stress ces temps ci

la semaine dernière, en plein pendant un week-end dans la famille, mon Galaxy S3 me fait le coup de la "mort subite". J'ai retiré 25 fois la batterie, épluché les forums ... en vain.


Bon, allez, y'a pas mort d'homme, et en plus voilà un prétexte tout trouvé pour commander le Nexus 5.

Lundi, allez hop soyons fou je migre mon MacBook sous Maverick. "upgrade gratuit" de la part d'Apple, j'aurais de me méfier. Aucun changement notable.

petite parenthèse : j'essaye "plan" vite fait, dont j'ai entendu tant de mal, et la photo aérienne de mon chez-moi est plus à jour et de bien meilleure qualité que google maps. Donc pour un gars qui vit dans sa campagne comme moi c'est plutôt positif ;)




Après l'ugrade, mon code d'accès à https (je bosse sur le plugin git jenkins) se met à planter - j'apprends qu'il faut réinstaller le java 6 Apple.

Bon, allez, y'a pas mort d'homme, c'est pas méchant ça m'a "juste" fait perdre une journée de taf, c'est pas comme si j'était grave à la bourre juste avant Devoxx.
Sinon R.A.S, ça reste un OSX quasiment tout pareil - ça m'aurait fait mal de payer un upgrade pour ça - jusqu'à ce que je décide de rebooter (quand git n'arrive plus à résoudre "github.com", c'est pas bon), après tout un reboot une fois par semestre ça peut pas faire de mal.

Titre tapageur - serais-je un peu provocateur ?


Non, je ne vais pas faire l'apologie de Clearcase, je suis très content de Git en tant que développeur et je n'ai absolument pas l'intention de changer, même pour un autre DVCS.

Par contre, je suis mainteneur du plugin Git pour jenkins. J'ai hérité de ce plugin sans trop savoir comment, au départ en backportant des correctifs utilisés par CloudBees puis rapidement faute d'une mainteneur en place. Et j'ai rapidement compris pourquoi : ce plugin est un amalgame de pull-requests en tout genre.

Le problème de la pull-request, c'est

1. quand on crée un patch, et donc une pull-request, on essaie de faire minimaliste. On ne fait pas un gros refactoring juste pour la beauté du geste. On va donc ajouter un "if (foo) { ... } else" dans le code existant. 25 pull requests plus tard la méthode fait 400 lignes et est incompréhensible.
2. si c'est un mécanisme de revue de code formidable, en opensource la pull-request a ce désagréable effet de bord de permettre à un contributeur de "balancer" du code par dessus le mur, sans s'impliquer forcément dans le projet. D'où l'absence de continuté sur ce plugin.

I recently discovered project to start a JSR for Configuration Management. Mike Keith introduced this project at JavaOne, you can download slides for his presentation here. I wasn't aware so didn't attend the live talk, but reviewing the slides I have few comments.

Proposal (afaik)

Scope for such a JSR is difficult to establish. If you want to embrace the existing tools, there is overlap with generic platform provisioning. I don't think this is a good idea to consider this until there's a reasonable consensus on application-level configuration management. Looks like this is also the diagnostic for this JSR.

The current state for JavaEE configuration is "JNDI" : if you need to inject some resources / parameter to an application, you have to provide some container-specific xml file in your WAR archive. This suppose Ops will unzip the WAR, edit xml to put production resource binding and credentials, then re-archive and deploy using container-specific commands. Nobody never did this. So this is a great idea to review this and provide something to better match actual practices and tools.

Also have to consider the DevOps impact on development/deployment practices.

Contract for configuration management is also complex to establish. Reviewing slides, the proposal seems to be to package application configuration in a CAR (configuration archive).


I think this is a very bad idea. For the same reason Ops don't unzip WAR to edit xml files, they won't do this to create CAR files. Ops tools and practices are based on scriptable solutions from system shell. I don't think we will see JavaEE apps packaged as RPM/DEB system packages, at least because Java is supposed to "run everywhere", not just on Linux distros. But a configuration management JSR must primarily focus on Ops practices, not on JavaEE developers. JSR use to define Java based API, I think this specific JSR must NOT use Java as primary language. My main concern with a java-based approach is that this will result in a new java.util.prefs.Preferences nobody is using.

My vision

I'd prefer the JSR to define a REST API application container (or platform as a service) have to expose to allow defining the configuration for an application. REST is neutral, well supported both from Java tooling and base script shell (using curl).

So, you can imagine a REST endpoint on your application server that let you define an "application" (unique ID) and bind server resources / configuration parameters to this application. Application server is responsible to implement actual persistence.

Deploying an application would then be :

1. create the application with unique ID
2. set application configuration 
• resource bindings (JDBC DataSource, JavaMail session, JMS queues, etc)
• simple parameters
• structured parameters (? - see later)
3. deploy WAR/EAR for application ID

Application configuration has to be persistent : it will survive application restart and redeployment, as long as application unique ID is unchanged. It's also idempotent: binding same resource twice don't result in a duplicated resource. This is a requirement for infrastructure automation tools (like Chef/Puppet) to work in this context.

Without any surprise, you probably notice how this proposal mimic CloudBees configuration management. We also support cloudbees-web.xml and some of us like it, but I consider this legacy. Using SDK to bind a Database to my application, whatever application server I'm using - Tomcat, JBoss, Glassfish, Jetty - and getting it injected as a JNDI DataSource is awesome.


How does application access configuration ?

Based on slides, JSR proposal defines a new API for application code to access configuration. So, you'll have to wait for all frameworks to be updated to benefit this API :-/

To workaround design issue for JavaEE to miss a configuration API, most framework rely on placeholders, the common denominator being support for system properties. I never have seen a JavaEE application to use String declared in JNDI, but I not a bunch of apps to get runtime settings from system properties. For adoption of a configuration management JSR, and immediate support on most frameworks, system properties must be considered as first-class citizens in configuration land.

Injecting a simple parameter in an application should result in getting the equivalent system property set. With system properties, you already can manage a bunch of use-cases. I'm not sure there's actual need for structured parameters. This could be addressed by JAXB / JSONB data binding anyway.

Conclusion

I'd be very happy to contribute this JSR. I've been looking for an "incubator" page for it but can't find this on jcp.org. I'm not sure then how expert group is established, but if I can join I'd be very happy to compare my point of view with others and help as much as possible to make this JSR a useful one.

1. Cloud != DataCenter

• ressources (quasi) illimitées, disponibles à la demande - ce qui ne veut pas dire sans quotas ni restrictions,
• accès direct par API, sans passage par la case "formulaire bleu à envoyer à l'admin signé par le CdP",
• mutualisation des ressources et facturation à l'usage,
• délégation complète de la maintenance et du support.