Discussion :

[grunt2000]

Bonjour,

Il y a peu, on essayait de débuter la construction d'une nouvelle application Spring 4
en reprenant des éléments d'une autre assez récente (deux ans d'âge), en Spring 4 également.

Au déploiement, voici qu'elle râle beaucoup. Des ressources de servlet /NONE qu'elle ne trouve pas, ou quelque-chose comme ça.
Nous cherchons pourquoi : c'est une classe utilitaire RestTemplateBuilder qui a fait penser à quelqu'un que profiter de Spring boot serait une bonne chose.
Mais de l'avoir déclaré, celui-ci veut que tout change pour son agrément. Sinon, visiblement, il ne sait pas se retrouver dans une application Spring standard. Il n'est pas compatible d'office, ne s'insère pas comme ça sans préparation.

Là, on se questionne. Pour passer en Spring boot on devrait restructurer nos applications pour la deuxième fois de leur existence :
la première avait été pour passer des déclarations de contexte en XML à celles par annotations,
et vivre avec les petits réglages qu'il voudra là, puis là, puis là, puis là ?
Est-ce que ça en vaut la peine de recommencer cette épreuve fastidieuse ?

Une boite noire supposée masquer des complexités (un terrible aveu de la trop grande difficulté des mécanismes d'injection et de paramétrage que propose Spring)
mais réclamant elle-même d'apprendre une nouvelle série de règles de paramétrage.
C'est un gag...

Spring 5 conservera t-il Spring boot qui n'a finalement pas l'air d'être si utilisé ?
Je n'ai pas vu d'applications volumineuses, encore, qui l'aient employé.
Et je me demande bien, en fin de compte, quel sens il veut avoir, et si son apport justifie de tout restructurer. Parce que derrière, il faut de nouveau former tout le monde.

C'est vraiment un bon cheval, Spring boot ? Ou on peut le laisser de côté ?

[Gugelhupf]

Salut,

Je pense que vous avez rencontré des difficultés liées à votre migration, avez-vous utilisé la plateforme Spring Initializr pour générer votre projet Spring Boot ?
Le coté "boite noire" a toujours existé avec Spring, le fait de passer d'une configuration XML à annotation pour déclarer ses beans n'y change rien. Je pense que je ne serais pas le seul à penser que Spring Boot simplifie grandement la configuration de l'application (sauf peut-être pour faire du Spring Batch), et rend le code nettement plus lisible. Personnellement, je ne me vois plus créer mes applications Web (ou non Web) à partir de Spring Core.
Il y aura toujours du Spring Boot avec Spring 5, la nouveauté de ce dernier c'est le Reactive Programming.

A+

[Pill_S]

Personnellement, je ne me vois plus créer mes applications Web (ou non Web) à partir de Spring Core.

Je serais un peu moins catégorique bien que d'accord: une config à la Spring Boot est beaucoup moins verbeuse que la même config en Spring Core. Même si la magie de Spring Boot peut sembler parfois un peu obscure (en comparaison, plus obscure qu'avec Spring Core) ça facilite grandement le démarrage, surtout lorsqu'une partie de l'équipe n'a aucune expérience de Spring.

Mais j'aimais bien aussi la liberté qu'on avait à l'époque où Spring ne s'était pas transformé en monstre tentaculaire agissant dans toutes les couches de l'appli. Fût un temps, on pouvait décider d'utiliser Spring modules par modules p.ex. uniquement pour de l'injection de dépendances et câbler le reste comme on voulait (éventuellement pour s'intégrer dans un écosystème existant, ou contrôler ses dépendances de façon fine dans les modules). Sans être complètement impossible à faire maintenant, Spring Boot ne l'encourage pas...

[Gugelhupf]

Salut,

Je n'aime pas l'idée d'intégrer Spring dans un écosystème existant, je pense par exemple aux projets Struts contenant du Spring, pourquoi complexifier l'architecture ? Spring est un framework très complet et se suffit à lui-même. Je trouve que Spring ne tend pas (ou plus) à s'intégrer dans d'autres projets mais plutôt à les intégrer (leurs concepts), nous perdons peut-être en "liberté" mais le framework est plus cadré.

A+

[grunt2000]

Salut,

Je pense que vous avez rencontré des difficultés liées à votre migration, avez-vous utilisé la plateforme Spring Initializr pour générer votre projet Spring Boot ?

A+

Je ne le connaissais pas. Merci beaucoup !

Je ne sais pas comment dire. Je n'ai pas envie d'apprendre à configurer Spring une troisième fois.
Quand je vois la référence Spring boot, qui va du chapitre 1.1 au chapitre 85.5, je me demande : "C'est vraiment simple... ?!".

Je n'arrive pas à savoir si les gens vont vraiment y aller ou s'ils vont rester sur des applications "à l'ancienne", fussent-elles en Spring 4 ou Spring 5.
Et puis, il y a le problème du retour en arrière induit par la mise en cohérence de leurs dépendances à laquelle ces "agrégateurs" doivent procéder, en interne :
Il y a un an, j'avais eu recours à votre aide pour avoir, sous Spring 4, des dépendances cohérentes entre elles. Vous m'aviez suggéré d'utiliser en BOM de référence la dépendance spring.io.plateform, platform-bom, très attractive. Elle avait de nombreux atouts, mais elle repoussait très loin en arrière certains composants : à l'époque, elle se limitait à Spring 4.2.x quand Spring 4.3.x était déjà là depuis longtemps.

Spring Boot ne pose t-il pas ces problèmes ? On l'utilise, mais à la condition de se limiter à ceci ou cela ?


Aujourd'hui, je voudrais passer en Spring Boot une application JSF 2 :
La dernière version du jsf-spring-boot-parent sur Maven Repository est la 2.4.0 (Juin 2017). En suivant ses dépendances, elle mène à du Spring boot 1.5.4 qui mène lui à du Spring 4.3.9.RELEASE : ce n'est pas trop grave, mais je vois aussi de l'Elastic Search 2.4.5 et il est en 5.5 aujourd'hui.
Ce jsf-spring-boot-parent a une liste de managed dependencies de 514 (!) entrées. Si je mets ça comme POM parent je vais avoir un binaire qui va faire un gigot, non ?
Et si le le mets en tant que BOM, il va falloir que je sache à quel moment il faut que j'incorpore en dépendance réelle telle famille de composants.