Quel serveur d'application pour application de gestion JEE
Bonjour,
Je développe un nouveau projet JEE sous Java 1.8 avec le framework Spring MVC, peut-être Hibernate, Bootstrap, BDD PostgreSQL, le tout sur un serveur Ubuntu 14.04 hébergé sur un VPS OVH.
J'ai déjà utilisé Tomcat il y a quelques années, mais GlassFish me tente ou pourquoi pas autre chose (JBoss...). Je voudrais connaître votre avis par rapport à mon besoin.
Qu'est-ce qui est à la mode dans les boites en ce moment ?
The eternal battle JBoss vs Spring
Le monde JEE est aussi puissant qu'il est éprouvant.
Spring permet une grande variétés de choses, est très modulable, mais il demande tellement de configuration qu'on se demande souvent "Quand est-ce qu'on commence à bosser avec sur le sujet qui nous intéresse vraiment ?"
Il est apprécié des informaticiens qui ont une vision "architecture technique" de leur application, mais moins par ceux qui ont une vision "traitements métiers" où l'on veut faire développer à de nouveaux arrivants rapidement quelque-chose de fonctionnel. Il est assez aisé de prendre un débutant et de le faire entrer sur un projet JBoss, et beaucoup moins simple de le faire entrer sur un projet Spring.
Ce qui est éprouvant avec Spring, c'est le désir de faire toujours quelque-chose d'autre même quand il n'y en a pas besoin. On se retrouve avec des situations dingues.
Impossible de déclarer une simple servlet qui n'adhère pas au modèle MVC de Spring sans se plonger longtemps dans la doc.
Spring Batch est génial, tout le monde vous l'a dit et vous devez l'apprendre par coeur (pas Spring Batch : mais le fait qu'il est génial), mais si vous ne parvenez pas à entrer dedans, je vous comprends très bien.
Spring MVC doit être la pire plaie de toute l'histoire de l'humanité,
et bravo à ceux qui arriveront à expliquer à des débutants spring-data, spring-jdbc, le modèle de transaction, l'ORM avec les déclarations de datasources, entity manager factory, transaction manager, etc... puis les repository... : on apprend aux gens la programmation XML.
Spring Boot est symbolique : sa présence est la concession par une partie de sa communauté que Spring est devenu trop compliqué. Et aujourd'hui, le gag, c'est que en plus de maitriser les modules core, batch, mvc, data, jdbc, web, security de Spring, on vous demande de maitriser Spring Boot ! Spring, un bon tiers du développement, c'est de la configuration. Et 20% supplémentaires, c'est se former et former les autres tellement c'est complexe. Dans mon esprit Spring est très puissant, mais il est "délirant". Le moment où l'on peut-être sur son strict code métier sans s'occuper d'autre chose est très court, est ponctuel. Spring en tant que tel avec toutes ses nécessités géniales et supposées vous simplifier la vie se rappelle à vous à chaque instant, d'un format hors JEE qu'il vous oblige à suivre, d'une cent-cinquantième config qu'il vous oblige à placer ici ou là, vous interrompant.
Impossible de résoudre un problème humain d'informatique en ligne droite sans l'emmêler des désirs perpétuels qu'il a, parce que c'est un framework trop prégnant. Et même les convictions entendues de ses adeptes : "Oui, mais c'est très modulable.", "Quand ce sera fini, tu verras", "C'est très puissant.", et les centaines de "Ce qui est bien avec Spring, c'est que..." – je raille, mais le fan-club a contribué à me le rendre épuisant – ne suffisent pas à excuser ce problème.
JBoss de son côté (car il n'y a que JBoss à s'opposer à Spring : les autres serveurs d'applications sont moins représentés), à eu son heure de gloire
dont il a bien profité à la manière du lièvre et de la tortue pour se faire dépasser en terme de fonctionnalités par Spring jusqu'à JEE 6.
Dans le courant de l'année 2012, JBoss qui n'avait rien d'autre à faire en a profité pour se suicider (comme ça, ça lui passait par la tête...), en devenant strictement payant, et pendant des années la communauté "des EJB" a végété sur l'excellent mais non mis à jour JBoss AS 7. Et ce n'est que des années après qu'enfin les versions Wildfly sont venues. Mais quel gâchis et quelle perte de temps !
JBoss, ça démarre et on peut y aller. On fait son site web tout de suite. On déclare une datasource en standalone, son persistance unit dans son code source et ça suffit.
Mais alors on est face à des déboires :
1) Impossible de tester les EJB facilement en tests d'intégration. Arquillian tout puissant qu'il soit est très long et complexe à configurer pour le faire fonctionner. Il est très lourd.
2) Il est pas toujours acquis que ce que l'on fournira dans son ear remplacera réellement les modules équivalents installés sur JBoss. Certains d'entre-vous se sont peut-être confrontés au fameux jar majora de JSF 2 de JBoss AS 7.1.1 difficile à contourner et qui empêche de déployer facilement des versions avancées de JSF 2. Idéalement, il faudrait n'utiliser dans son application que des composants aux versions des modules présents dans JBoss en faisant exclure tous les autres par des <dependency> exclude.
Si vous aimez les pom.xml aux allures d'épitaphe, c'est bien : parce que ça va vous faire le POM de l'année : plusieurs centaines de lignes.
3) Le CDI. Va pour @Inject et @Named. Mais @Qualifier, @Alternative etc. qui connaît, qui comprend ? Comment s'y sont-ils pris pour expliquer cela aussi mal ? Vous avez déjà réussi à parcourir toute une doc sur le CDI dans JEE en entier, vous ? Moi pas. C'est tellement étrange et tarabiscoté les exemples d'emploi que je n'ai jamais réussi à m'y projeter vraiment. Là encore : c'est sûrement puissant, mais pas très intelligible.
Je suis sévère avec les deux systèmes. Le problème de fond, c'est qu'un nouveau venu avec zéro à deux années d'expérience il doit pouvoir bosser quelque-part.
Et tous les frameworks qui réclament une expertise trop forte, je les dénonce. Certaines fois des annonces d'emploi réclament huit années d'expérience pour entrer sur un projet employant l'un d'entre-eux. C'est bien trop ! C'est un aveu d'échec.
Ils doivent se simplifier s'il le faut pour devenir plus accessibles. Les JSR pourront peut-être, à terme, les réunir sous l'égide de règles communes.