Archives de Catégorie: Spring

JHipster

Hier j’ai parlé de Spring Boot qui fait parti des projets Hype du moment pour tout développeur Java. En fait la problématique c’est comment démarrer rapidement un projet web (ou autre) ? Spring Boot répond à ce besoin de pouvoir faire un site web ou une API Rest (ou encore une fois autre) en quelques lignes de code.

Cependant en parallèle Node.JS est devenu très populaire car le Javascript est devenu très populaire (Node.JS c’est du Javascript coté serveur ET en asynchrone : bonus XXL).

Mais voilà Spring Boot est un bon départ mais après il reste à faire une interface avec Angular JS (ça aussi c’est Hype, enfin surtout pour un backoffice ou une application de gestion, mais en tout cas j’adore), mais aussi lier à une une base de données (MongoDB c’est Hype, MySQL/PostgreSQL c’est aussi pas mal pour structurer ses données), loguer, mesurer, déployer, etc …

La solution ? Le projet JHipster ! Il s’agit d’un projet géré via yeoman c’est à dire qu’il faut installer Node.JS (tiens encore lui) et d’installer yeoman via npm, le gestionnaire de package de Node.JS pour enfin avoir la commande yo afin de faire un petit yo jhipster et de répondre à toute ses questions (choisir sa base de données, son gestionnaire de package, la manière d’identifier un utilisateur, etc.). JHipster consiste à la fois à du code Java (une API Rest + des templates délivrés à Angular JS) mais aussi à une interface de type SPA avec Angular JS, BootStrap, etc avec l’utilisation, en bonus de très bonnes librairies comme Metrics ou Swagger.

Jusqu’à maintenant je connaissais les archétypes maven, notamment le kickstart de Spring 4 MVC ou encore les quickstarts de JBoss ou encore JBoss Forge mais aucun ne faisait du fullstack en alliant le monde Java (via Spring) et le monde Javascript (via Grunt/Bower/etc.). C’est donc chose faite via JHipster et en plus via une SSII français aka Ippon Technologies (société auquelle j’avais postulé en 2008, je regrette parfois de ne pas avoir accepté la proposition finale). Le site web lié explique très bien comment cela fonctionne, comment l’installer, comment le déployer, etc. Bref, bravo. Après certaines choses ne me conviennent pas (je suis très difficile) à savoir que je préfère utiliser un serveur Java EE plutôt que tomcat et donc d’utiliser des DataSource(s) (tomcat peut le faire) l’utilisation de JTA/JPA et si possible de JAX-RS (via Jersey ou RestEasy) voir plus si possible (qui peut le plus peut le moins).

Donc JHipster est une très bonne base pour un projet Hype, mais, comme toujours, demande de l’ingénierie pour l’adapter à son propre contexte.

Note à part : JHipster fonctionne sous WildFly 8.1 il suffit juste de ne pas intégrer les librairies tomcat-*.jar dans le WAR généré. Par contre je ne suis pas arrivé à intégrer Spring Boot en tant que module dans WildFly. Donc le WAR fait plus de 50Mo et n’est pas allégeable avec WildFly. Si le serveur d’intégration continue est en entreprise mais que le déploiement est dans un cloud privé alors cela est problématique de transférer 50 Mo à chaque déploiement … A travailler.

Spring Boot

J’utilise Spring depuis maintenant 3 ans (depuis ma formation en DIF en fait) et en voulant moderniser nos sites web écrit en Spring 3.x je suis tombé sur le projet Spring Boot.

Le principe premier de Spring Boot est de pouvoir démarrer un projet en quelques lignes de code … avec Spring. Il y a même eu un tweet (donc maximum 140 caractères) qui est un code pouvant lancer un serveur web et répondre sur une URL. De la même façon une API Rest minimaliste pourrait donc aussi tenir dans un tweet.

Note à part : si vous connaissez node.js cela ne vous rappelle rien ? On dirait que Spring Boot est une réponse au succès de node.js et à la création « les doigts dans le nez » d’un site web ou d’une API Rest en un rien de temps. Spring Boot permet même de lancer une ligne de commande un serveur web exécutant un code minimaliste ou de créer un livrable prêt à lancer un serveur web en production. Spring Boot s’inscrit dans le la notion de RAD dans l’univers web.

Pourquoi Spring Boot et non simplement Spring (ou Spring MVC pour un site web) ? A cause de la configuration … Spring est très bien pour délivrer des petits bouts fonctionnels mais l’agglomération de tout ces petits bouts est couteux. Là où intervient Spring Boot est qu’il détecte ces petits bouts et les configurent au mieux que possible.

Mais comment les détecte t-il ? Via les librairies présentent dans le classpath ! Par exemple si dans votre projet vous mettez (comme moi) la librairie freemarker alors il se dit qu’il faut configurer Spring MVC afin qu’il puisse utiliser des templates freemarker et que ces mêmes templates sont dans /templates/ (vis à vis du classpath).

Mais, n’est-il pas trop « aggressif » dans sa manière de fonctionner ? Oui et non. C’est vrai que du coup Spring Boot est très ce qu’on appelle « opinionated » (terme très en vogue dans les framework web) c’est-à-dire qu’il gère les composants de la manière qu’il lui semble optimale mais sans que ce soit à votre manière. Cependant sa philosophie c’est d’être « opinionated » mais de pouvoir à tout moment prendre le dessus (la philosophie première de Spring en fait). Et justement il facilite la prise en main d’une fonctionnalité particulière.

Donc en clair il suffit de créer un projet Maven en déclarant que le pom parent est spring-boot-starter-parent et de choisir une dépendance avec un « starter » et hop … il suffit de créer un contrôleur comme le tweet ci-dessus puis de faire un

> mvn spring-boot:run

et on a un site web fonctionnel !

(cela peut aussi être fait avec Gradle, c’est selon l’environnement de travail)

Bon Spring Boot n’est pas que cela il y a de nombreuses autres fonctionnalités que vous pourrez consulter dans la documentation de Spring Boot.

Je dois quand même avouer, avec mon expérience de Spring, qu’il s’agit d’une facilité bienvenue. Combien de fois ais-je dû me demander commander intégrer tel ou tel composant dans Spring ?

Et puis pour aller encore plus loin, Spring Boot est assez bien intégré avec le Cloud. Donc, par exemple, développer une API Rest sur Heroku est « assez rapide ». Spring Boot donne toutes les instructions nécessaires pour un déploiement dans le cloud via les acteurs majeurs de la place. Voir içi (tiens d’ailleurs Google Application Engine n’est qu’en version Servlet 2.5 !).

Pour bien commencer avec Spring Boot et en français voici un article intéressant.

Alors en conclusion je dirais que Spring Boot est très intéressant surtout pour démarrer rapidement un projet (web/rest/batch/etc…) MAIS la contremesure c’est d’apprendre une surcouche de Spring (Spring Boot) en plus de Spring lui-même. Il y a de nouvelles annotations, de nouvelles classes, de nouvelles librairies, de nouvelles façon de faire mais il faut quand même connaître Spring pour, au fur à mesure, aller plus loin dans le développement. A coté il y a Java EE 7 … (que j’utilise déjà pour d’autres briques de notre système d’information). Quand je regarde le code de spring-boot-*.jar  (notamment spring-boot-autoconfigure-*.jar) je me dis que ce n’est plus la même manière de fonctionner qu’auparavant. Mais après tout Spring Boot est pour nous aider à démarrer un projet et non nous contraindre sur l’apprentissage de nouvelles annotations.

Dernier point (oui encore un) j’ai une appréhension sur la manière dont Spring Boot fonctionne : il analyse le classpath à la recherche de librairies (en faite de classes) permettant de déclencher certaines fonctionnalités (tiens au fait Java EE ne fait pas déjà cela ?). Cependant cette même gestion de classpath au sein de Java est problématique car non adaptée (à mon sens) à une gestion moderne de librairies. Je fais en fait référence à la JSR 277 (Java Module System) qui devrait modulariser Java mais qui est en cesse repousée (Java 9 ou Java 10 ?). Cela aura un impact assez lourd sur le ClassLoader de Java et du coup, par rebond, à Spring Boot.

Et puis aussi avec ce dernier point je dois préciser que j’utilise dès que je peux JBoss AS 7 / WildFly 8.1. Je trouve que c’est un superbe serveur d’application et le serveur web n’est plus tomcat (sur WildFly) mais Undertow que est extra-performant et fait partie des meilleurs serveurs mondiaux (par exemple, attention je suis conscient que cela dépend de beaucoup de paramètres et que node.js peut être plus performant, ou même d’autres !). Et concernant Sprint Boot cela fonctionne sous WildFly mais sous peu que TOUTES les librairies soient dans le WAR lui-même. Le problème ? C’est j’aime bien mettre les librairies sous forme de modules dans JBoss AS 7 / WildFly MAIS que du coup la gestion des classes de ces modules n’est pas celle attendue par Spring Boot et donc aucune fonctionnalité mise en module n’est détectée. Pourtant j’ai insisté pendant plusieurs jours (voir nuits) mais impossible à faire détecter les modules par Spring Boot (pour l’auto configuration) … J’en suis arrivé à la conclusion que Spring Boot fonctionne sous JBoss AS 7 / Wild Fly mais que toute librairie nécessaire doit être dans le WAR et que tout module ne sera pas détecté pour être auto-configuré. Donc retour aux FAT-WAR(s) que je déteste tant … ou alors je continue d’utiliser Spring en mode classique, à voir.