Version imprimable
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 ?
Ben dans ce cas ce serait bien d'exprimer quel est ton besoin :aie:
Tout dépend de ce que tu veux gérer: WildFly et Glassfish sont des serveurs JavaEE. Ils te fournissent l'API JPA (donc pas Hibernate directement) et d'autres API standards. Ils ont aussi des outils d'administration un peu plus évolués que Tomcat.
L'avantage de Tomcat c'est que tu gères tout à la main. Bref tout dépend de ton besoin.
J'ai un petit serveur OVH VPS SSD1 avec seulement 10Go d'espace et 2G0 de RAM donc un outil qui n'est pas trop gourmand est mieux.
Quelles informations vous faut-il de plus pour me conseiller au mieux ?
WildFly tourne sur un PI ;o) mais bon faut un peu le tuner.
Il existe aussi une version 'servlet' de WildFly qui est sûrement plus légère après j'ai pas comparé avec un Tomcat.
Personnellement je ne vois pas trop l'intéret d'un spring-mvc surtout si tu fais du bootstrap mais bon j'ai pas utilisé depuis longtemps.
Si tu veux un truc pas trop gourmand tu as Jetty et Tomcat (ce sont des servlet container), si tu veux un serveur d'application respectant la spécification Java EE tu as plusieurs choix : WildFly (la version non-entreprise de JBoss) ou GlassFish par exemple. Tous dépend de ton besoin, en théorie si tu souhaites utiliser le framework Spring, ce dernier embarque le nécessaire pour faire de l'injection de dépendance je crois, donc un Tomcat devrait suffire. Si tu veux utiliser un maximum la spécification Java EE (JPA, JMS, EJB, CDI etc), il faudra te dépatouiller avec des dépendances que Jetty ou Tomcat n'embarque pas.
PS: Rien ne t'empêche de faire du Bootstrap (Twitter) ou connecter ton application à une base PostgreSQL avec du Jetty ou Tomcat.
Bonjour,
Tomcat ou Jetty, suffisent.
Glassfish ou Jboss c'est trop lourd, c'est fait pour de l'EJB/CDI
c'est comme utiliser un char d'assaut pour aller chercher une baguette.
sinon pour le fun EJB Lite tu as Tomee, Tomcat + OpenEJB.
Olivier
tu peux envisager alors de remplacer Tomcat en utilsant vert.xCitation:
Envoyé par Tanebisse
http://thierry-leriche-dessirier.dev...ster-verticle/
http://vertx.io/
@nathieb : moi ca me fait un peu rire de dire que Jboss/Wildfly c'est lourd à cause des EJBs (que tu peux enlever, il existe une distribution servlet only) et de CDI alors que tu vas te coltiner une application Spring MVC avec Spring, Spring Data, SpringWeb et tout le bousin qui vient avec.
Glassfish comme WildFly sont modulaires et tu peux retirer les modules qui ne t'intéressent pas (cf distribution Servlet only ou WildFly Swarm). Tu peux même mettre juste un Undertow avec son extension Servlet si tu veux réduire au minimum.
Après Java EE a tendance à mettre du CDI de partout donc c'est sûr que de retirer Weld ça va devenir de plus en plus délicat mais en même temps CDI pousse pour pouvoir s'exécuter en J2SE.
Eclipse Vertx c'est un changement de paradigme donc tout dépend de ce que tu peux "investir" en terme de temps et de risque.
Il y a surtout que je ne vois pas trop l'intérêt d'un serveur comme JBoss ou Glassfish quand on utilise Spring, Tomcat ira très bien, pourquoi changer ?
L'intérêt d'un serveur JEE est dans l'usage de la norme JEE, pas d'un concurrent comme Spring...
JEE et Spring sont clairement concurrents et partenaires d'innovations a la fois. D'ailleurs, de nos jours avec l'injection et tout le tralala, tu passes de l'un a l'autre tres facilement, dans certains cas sans meme avoir a changer de code.Citation:
Envoyé par OButterlin
Au final, si tu vas pour utiliser Spring, alors tu te retrouves a faire ton serveur d'app en prenant Tomcat et en y ajoutant ce que tu veux. Si tu pars d'un serveur d'app JEE, alors tu as deja tout et tu n'as pas a te creer ton serveur. Comme le dit ehsavoie, le Tomcat plus leger est maintenant une legende du passe. Quelques metriques tres recentes montrent qu'utiliser Tomcat plutot qu'un serveur JEE, c'est des economies de bout de ficelles: http://antoniogoncalves.org/2016/02/...here-art-thou/ , la modularite des serveurs d'application a bien remis tout en cause. Par exemple, la partie EJB de WildFly ne coute rien tant que tu ne l'utilises pas.
Bref, c'est une question de point de vue: est-ce que tu preferes avoir un serveur complet fourni par un tiers, meme si tu ne vas pas l'utiliser a 100%, ou te faire ton serveur a toi... Perso, je suis plutot favorable a ne pas me prendre la tete a packager un serveur, et a prendre un truc qui marche de A a Z direct, pour me concentrer sur mon appli immediatement.
Mais au final, que ce soit avec un serveur Tomcat+Spring ou Java EE, tu vas utiliser les memes paradigmes, voire meme les meme frameworks sous-jacents, les memes technos, pour ecrire un code quasi identique, avec une meme productivite et un meme rendu a l'utilisateur final...
Ayant fait de l'EJB Session, CDI, Spring IoC, il faut forcément changer les annotations, donc le code change.Citation:
D'ailleurs, de nos jours avec l'injection et tout le tralala, tu passes de l'un a l'autre tres facilement, dans certains cas sans meme avoir a changer de code
Heu non les annotations spring sont les même quel que soit le conteneur. Et les annotation cdi ejb jpa sont standardisées avec un bémol en jpa pour les zones d'ombre de la spec. Donc le code n'a pas a changer d'un conteneur jee a l'autre supportant la même spec.
En même temps on fait du Java donc forcément on n'aura pas à changer le code si on reste sur un même Framework/API. Je n'ai pas fait le rapprochement avec les serveurs d'applications, ce que je voulais dire, c'est qu'entre Spring IoC, EJB Session et CDI, on fait de l'injection de dépendance, mais qu'entre ces différents API il faut rester cohérent (ex : ne pas mélanger les annotations, que si on veut passer de l'un à l'autre il faut changer les annotations etc). J'ai d'ailleurs rédigé un article entre JAX-RS et Spring MVC : dans les faits on fait la même chose, mais en pratique on change juste les annotations (lien), je pense faire de même avec EJB Session / Spring IoC / CDI si je trouve un peu de temps.
Le problème est plutôt lié à l'hébergement (serveur OVH VPS SSD1).Citation:
Envoyé par Mickael_Istria
Je ne sais pas où ça en est mais à l'époque, ils étaient souvent préinstallé avec un Tomcat, d'où Tomcat + Spring...
Personnellement, je développe tout sur JBoss, comme tu dis, tout y est, pas de prise de tête pour inclure d'autres éléments et depuis JBoss7, ça démarre super bien ;)
Bonjour,
Dans le cadre d'un projet mobile (perso) je viens de découvrir OpenShift,
tu as le beurre, l'argent du beurre, bon la crémière cela va être difficile.
Il propose un cloud avec Tomcat ou Jboss voir un Diy (do it yourself), je suis en ce moment
sur le déploiement d'un TOMEE, histoire de tester.
C'est easy, gratuit et franchement il y a du choix et de l'espace.
Dommage qu'aucun hébergeur francais puisse proposer de telles solutions.
Olivier
+1. OpenShift m'avait fait très bonne impression quand je l'ai essayé, tu démarres un appli visible super vite, sans avoir trop à réfléchir à tout ce qui est sécu et scalabilité qui sont déjà suffisamment bien géré pour démarrer sans risque. J'avais créé un compte, cliqué la case "avoir wildfly" et j'avais plus qu'à faire un push de mon projet GitHub pour que ce soit deployé publiquement en quelques minutes. En quelques minutes, j'ai eu mon Hello World là où il m'en avait fallu plusieurs heures pour un moins bon résultats dans mes précédentes expériences.Citation:
Dans le cadre d'un projet mobile (perso) je viens de découvrir OpenShift,
tu as le beurre, l'argent du beurre, bon la crémière cela va être difficile.
Il propose un cloud avec Tomcat ou Jboss voir un Diy (do it yourself), je suis en ce moment
sur le déploiement d'un TOMEE, histoire de tester.
C'est easy, gratuit et franchement il y a du choix et de l'espace.
Ils pourraient s'ils le voulaient: OpenShift est open-source apres tout. Apres, c'est une question de strategie: Red Hat a pris le tournant DevOps en faisant une offre cloud/infra agréable pour les devs; alors que pas mal d'autres hebergeurs restent tres orientés pure infrastructure.Citation:
Dommage qu'aucun hébergeur francais puisse proposer de telles solutions.
Après, pour ce qui est chauvinisme, vu le nombre de recrue que fait Red Hat en France en ce moment, ça deviendrait presque un produit de notre terroir ;)
Quitte à vouloir aller vers la légèreté je vous conseille Undertow avec l'extension Servlet (voir même sans si vous n'y êtes pas lié). Tu peux même packager pour en faire juste un main avec ton war ;) Ca prend très peu de ressources, il supporte HTTP2. Mais la vraie source de consommation de mémoire / CPU ça reste l'application. Donc j'ai encore un doute sur la légèreté de Spring MVC pour ça.
Oui OpenShift c'est de la balle pour prototyper, d'ailleurs pas mal de grosses entreprises francaises l'utilisent en 'cloud interne'. C'est d'ailleurs une des raisons pour lesquelles on avait une journée "Université" (aka workshop) OpenShift au SnowCamp, parce que c'est génial pour le développement.
OK merci pour tous vos retours, je suis parti su un classique Tomcat et me suis inscrit sur Openshift en plus de mon VPS. Il n'y a plus qu'à le tester !
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.
Pour Spring je ne vais pas le défendre car je partage ton avis. Pourtant j'ai été un early adopter comme on dit, mais au final ca devient vite complexe et avec des dépendances de partout qui sont très contraignantes.
Pour JavaEE (car tu oublies un peu vite TomEE, GlassFish, Paraya, WAS et Weblogic) c'est une norme (JSR) donc ca évoue moin svite.
Enfin tes reproches sur JBoss AS 7 et le temps de sortie de WildFly oublient un peu vite qu'on passe de JavaEE 6 à JavaEE7. Et c'est sans compter les utilisateurs qui se plaignent des sorties trop fréquentes de WildFly depuis.
Les développeurs ne vivent pas que d'amour et d'eau fraiche ;) Cette action de créer EAP répondait en fait à une demande de certains utilisateurs qui voulaient un package mieux garanti quitte à le payer, ce qui tombe bien parce que de l'autre côté, les développeurs demandent des sous pour coder. Ce n'était dont pas un suicide ou une folie, c'était une opportunité d'avoir du retour sur investissement sur le serveur d'application, permettant de continuer un dévéloppement pérenne du serveur (OSS aussi bien que commercial).Citation:
Envoyé par grunt2000
C'est pas vraiment vrai ça. Il y a toujours eu et il y aura toujours une version OSS du serveur. Après, il y a eu un moment où ce n'était pas la priorité des principaux développeurs de l'avancer, mais il n'est pas devenu payant pour autant.Citation:
en devenant strictement payant
Si EAP n'était pas là pour ramener des $$$, il n'y aurait peut-être jamais eu de resources pour développer WildFly...Citation:
Mais quel gâchis et quelle perte de temps !
Le comportement est spécifié (par la spec Java EE je crois): les modules du serveur d'app prennent le dessus. Mais il y a moyen de configurer ça: https://docs.jboss.org/author/displa...ing+in+WildFly "Prevent automatic dependencies from being added".Citation:
Il est pas toujours acquis que ce que l'on fournira dans son ear remplacera réellement les modules équivalents installés sur JBoss.
Là-dessus, je suis d'accord. Après, c'est comme tous les frameworks: les cas de base sont simples car ils résolvent les problèmes simples; mais ça se complique au fur et à mesure que le problème se complique (malheureusement beaucoup de problèmes compliqués n'ont pas de solution simple). Au final, le @Qualifier et compagnie, mieux vaut ne pas s'y intéresser tant qu'on n'en a pas besoin et ne pas chercher à introduire leur complexité pour résoudre des problèmes simples.Citation:
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.
Bref, CDI c'est facile jusqu'au moment où on veut faire des trucs compliqués.
La je pense que le problème est plus dans la formation: quand on adopte un framework structurant, il est important de former les nouveaux venus. Soit ça doit se faire à l'école (mais vu la myriade de frameworks c'est pas évident d'en enseigner juste un et surtout le meilleur pour la carrière de l'étudiant), soit il faut que les entreprises prennent leurs responsabilités en laissant l'opportunité aux développeurs de se former avant d'agir. Payer des bouquins, laisser du temps libre pour apprendre une techno, payer des formations... il y a des manières de faire.Citation:
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.
La on parle de Java EE, mais l'exemple est tout aussi vrai sur PHP avev Symfony ou Zend, ou JS avec Angular. Les frameworks ça peut devenir compliqué, ça demande plus que de savoir faire un Hello World.
De mon point de vue, surtout sur ce forum, je vois des gens se lancer dans JavaEE sans comprendre les base du Java, et ça, c'est suicidaire. Difficile d'expliquer JavaEE à un débutant et pour cause, ça ne vise pas les débutants dans le language. Toutes ces api (CDI, EJB, JMS, ...) ça nécessite au préalable la maitrise de certaines notions: les transaction, les classloaders, les annotations, les generics, les interfaces, le multithread, ... Je pense qu'il est inutile de se lancer dans du javaEE si on n'a pas au moins 6 mois d'expérience temps plein en java.
Arquillian est difficile à configurer oui, sur des projets complexes. Si ton projet c'est du maven et que t'as suivi les instructions de maven pour installer et configurer tout, utiliser arquillian se résume à mettre le plugin dans ton pom.xml. De plus tu ne le configure qu'un seule fois, pour toute la vie du projet. Passer 2~4 jours à le configurer sur un vieux projet qui n'a jamais été testé, c'est donc tout à fait acceptable vu le gain. N'oublions pas non plus qu'arquillian lance des tests d'intégration, ça nécessite pas mal d'infrastructure: un serveur EE, des bases de données similaires à la prod, ... Rappelons aussi qu'en général tu peux tester tes EJB sans serveur: ce ne sont que des classe java, il suffit de les instancier, de les initialiser dans le test et d'appeler les méthodes. Pareil pour les beans CDI et les MDB.
Pour la doc, je trouve au contraire qu'oracle fait de gros efforts pour la rendre plus lisible depuis quelques version, et la doc CDI est bien claire http://docs.oracle.com/javaee/6/tutorial/doc/giwhl.html Pareillement, les Qualifier sont très bien expliqués http://docs.oracle.com/javaee/6/tuto...oc/gjbck.html: c'est une annotation custom que tu met sur un bean pour discriminer en cas d'ambiguité. Par contre si t'essaie d'apprendre en lisant les 800 pages dela Spec, ça, c'est indigeste, mais c'est destiné aux créateurs de serveur java ou à celui qui veux une précision sur un point obscur :)
Pour JBoss: ça a toujours été la galère pour remplacer les composants standard mais, ces composants faisant partie de la spec JavaEE, si tu fais une application javaEE, tu n'a pas besoin de remplacer ces composants. C'est encore une fois une opération que tu as rarement besoin de faire. J'ai ici de grosse application javaEE avec du jboss 4 et du wildfly 9: on n'a pas besoin de le faire, on utilise au maximum le standard.
@Mickael_istria, sur le sujet des débutants :
Sitôt l'étudiant sorti de l'école, la première entreprise venue lui proposera un sujet JEE (qu'il soit EJB ou Spring) parce qu'il n'y en a pas d'autres. Ou alors très exceptionnellement.
Le jeune il arrive avec son Bac+2 Java, zéro année d'expérience, il devrait trouver un job. Or, à l'inverse de ce qui se passe pour les offres PHP où de nombreuses sont destinées aux débutants, c'est une inflation des années d'expérience réclamées que l'on observe dans celles Java, et cette expérience qui est demandée, elle est demandée sur le framework cible. Et c'est là qu'il y a une erreur.
Pourquoi ?
1) Le DSI a ouvert un poste parce que dans 80% des cas, la MOA ou la direction lui a demandé de faire évoluer ou de créer de nouveaux traitements métiers.
Ce sont des services de l'entreprise qui ont besoin de :
- nouvelles pages web de saisie de configurations d'articles vendus,
- nouveaux batchs de traitement de commandes,
- contrôles d'ordre de fabrication,
- états analytiques comptables spécifiques.
- etc.
et le DSI ne peut de toutes façons que s'exprimer en termes métiers vers sa direction qui ne comprendrait pas d'autres discussions que celles sur l'avancée des développements dans les processus métiers de l'entreprise et les règles de gestions choisies ici ou là.
2) Le rôle d'un framework est de faciliter le développement. Pour simplifier, un bon framework devrait me permettre de me limiter à faire mes implémentations dans les couches objets métiers, service, web et coordination / contrôleur, sans rien me demander de plus.
Or que se passe t-il ? On demande à chaque développeur de savoir faire le développement métier (ce qui est normal), ainsi que d'avoir la très bonne compréhension du framework dans lequel il s'inscrit et savoir assurer sa configuration. Choses qui ne s'acquièrent (si on si intéresse) qu'après un bon nombre d'années.
Alors que ça n'a pas de nécessité.
Dans la mesure où avec le temps, les configurations se font en nombre de plus en plus limité (on en fait beaucoup au début, et puis après, elles y sont quasiment toutes), c'est à l'architecte JEE (ou au tech leader) de l'entreprise de s'en occuper et dans l'absolu je trouve légitime qu'il ait ces rôles :
- s'il y a une complexité dans le framework, mettre en place les classes d'entreprise parentes ou autres dispositifs qui permettront de passer l'obstacle le plus facilement possible.
- s'il y a un standard ou une bonne pratique à faire connaître et qu'il pense qu'il n'est pas acquis que tous la connaissent, il ne doit pas se formaliser de devoir l'expliquer, fût-ce souvent.
- il est le seul qui intervient dans les applicationContext.xml et standalone.xml. S'il s'aperçoit que ça lui est pénible de devoir intervenir trois fois par semaine sur l'applicationContext.xml au nom de l'un ou l'autre développeur, il sera le plus concerné pour trouver comment limiter ces désirs sans fin de configurations de Spring.
- il gère les évolutions de versions de composants JEE et API.
En un mot, l'architecte JEE doit rendre le framework invisible. C'est son job. Et à mon sens, il n'en a pas d'autres.
En exagérant et en poussant à la limite, je pourrais écrire mes méthodes de service dans un @Named, et ne pas savoir si c'est un @Service de Spring ou un @Stateless d'un serveur d'application que j'ai derrière ! Je n'ai pas besoin de le savoir.
Et c'est ainsi que l'on peut prendre des débutants connaissant seulement :
- un framework web : JSF, Angular, Struts, GWT...
- JPA 2 (même pas Hibernate : l'architecte JEE doit le dissimuler ; même pas les mappings entités <-> objets métiers : c'est aussi à l'architecte JEE de les dissimuler, à lui d'être un pro de Dozer et autres ; et même MongoDB c'est du JPA quand on s'y prend bien : là aussi l'architecte il doit faire que les développeurs arrivent doucement à MongoDB et non pas demander à ce qu'ils le connaissent déjà).
et c'est tout ! Et encore : moi, je n'ai besoin que d'un débutant connaissant le framework web : JPA avec le temps, je l'y forme. D'autant que normalement, si le taf il est bien fait : il y a des DAO depuis longtemps pour esquiver JPA, et je n'ai même pas besoin qu'ils le connaissent.
Les transactions, le débutant, il n'a pas besoin de connaître (on se démerde pour que tout passe en REQUIRED par défaut et on règle les adaptations exceptionnelles derrière son dos, s'il le faut). On lui expliquera les choses avec le temps.
Les objets métiers on peut lui apprendre comment les faire bien en live.
Les batchs on lui apprend le principe en ayant simplifié le mécanisme des batchs du framework pour les rendre utilisables avant.
Le débutant il doit se concentrer sur le métier. Sur rien d'autre. S'il s'occupe d'autre chose, c'est que l'architecte JEE / Tech leader il a mal fait son boulot.
On a besoin que d'un seul architecte pour assurer tout cela avec une bonne cohérence. Mais il faut qu'il le fasse. En entretien, il est fréquent que l'architecte JEE ait le toupet de poser des questions aux candidats pour savoir s'ils savent faire... ce qui est son job à lui ! Et je suis sidéré et assez exaspéré par cela.
Une entreprise où l'architecte JEE / tech-leader bosse bien est libre parce qu'elle peut avoir plein de développeurs de zéro à dix ans d'expérience (avec un bagage fait de : web + JPA seulement) qui agissent strictement sur des problèmes métiers de plus en plus complexes,
une entreprise où l'architecte JEE est un gargarisateur, il parle et critique, mais répartit le boulot parmi les développeurs et en fin de compte, ceux-là ne se concentrent plus sur leur tâches métiers mais s'interrompent quotidiennement sur des problématiques de configurations et d'architecture technique, et pour lesquels il faut une liste à rallonge de compétences et un minimum d'années d'expérience.
Donc, pour moi aujourd'hui, le problème en entreprise vient de l'architecte JEE. Une fonction qui est bien trop vite accordée à l'unique personne qui doit l'avoir, sans prendre le temps de vérifier si elle voudra bien libérer l'équipe de développement des contingences du serveur d'application choisi.
@tchize, sur le remplacement des composants standards de JBoss
C'est vrai ce que tu écris. Il faudrait se limiter à l'emploi des composants standards de JBoss.
Mais dans 100 à 150% des entreprises qui utilisent JBoss depuis plus cinq ans, tout redéfinit tout et l'on est souvent aux prises avec des jar hells à la façon des DLL hells de l'époque C++ de Windows.
JBoss et Spring sont deux choses complètement différents, l'un est un serveur d'application qui respecte les spécifications et te permet de développer une application en standard Java EE, l'autre (Spring) est un framework à part. Cependant il y a autant d'apprentissage avec les commandes JBoss + les spécifications standard Java EE que pour faire du Spring (qui lui utilise de manière transparent Tomcat par défaut).Citation:
Envoyé par grunt2000
Oui, mais c'est le cas de tout les produits dont tu souhaites étendre les fonctionnalités de base (et je ne pense pas seulement au domaine de l'informatique). Pour le cas de Spring, c'est simple : t'es Spring ou t'es pas Spring (ça fait un peu "tu l'aimes ou tu la quitte" désolé ce n'était pas volontaire :aie:).Citation:
Envoyé par grunt2000
Ben en fait, pas tant que ça, tu reprends la spec JAX-RS et tu changes les annotations (j'ai rédigé un article là-dessus), et pour être franc venant du standard, j'ai eu beaucoup plus de facilité à mettre en place une application Spring MVC que JAX-RS avec l'implémentation Jersey dans un servlet container Tomcat. De plus Spring MVC gère implictement le mapping des objets (avec Jackson).Citation:
Envoyé par grunt2000
=> C'est ce qui arrive quand on reprend un concept existant (Spring IoC) et qu'on change les noms pour éviter le plagiat.Citation:
Envoyé par grunt2000
Vous êtes bien bon messire !. Sauf qu'on est loin de la réalité du marché :aie:.Citation:
Envoyé par grunt2000
Bon perso j'ai commencé avec le standard Java EE et ça reste pour la référence en terme de développement web en Java, cependant Spring n'est pas si mauvais. J'ai étudié Spring 3 durant mes études, époque à laquelle on utilisait encore le fichier applicationContext.xml pour configurer les beans... cependant avec Spring 4 (et donc Spring Boot), tout a été simplifié à un niveau monumentale :
Avantage : plus de XML, tout est full-annotation, pas de problème lié au cache du container lorsqu'on modifie juste un passage du ficher XML (cf: web.xml pour Java EE est une plaie aussi) vu qu'il n'y a plus de XML.Code:
2
3
4
5
6
7
8
9
10
11
12
JAXRS le fait aussi : jackson est present dans Resteasy par exempleCitation:
Ben en fait, pas tant que ça, tu reprends la spec JAX-RS et tu changes les annotations (j'ai rédigé un article là-dessus), et pour être franc venant du standard, j'ai eu beaucoup plus de facilité à mettre en place une application Spring MVC que JAX-RS avec l'implémentation Jersey dans un servlet container Tomcat. De plus Spring MVC gère implictement le mapping des objets (avec Jackson).
Mince j'ai toujours cru que les gens de Spring faisaient partie de la JSR ;o) Java EE standardise sur des solutions éprouvées (comme JPA basé sur Hinernate JDO et Toplink), CDI s'est standardisé en partie sur Spring.Citation:
=> C'est ce qui arrive quand on reprend un concept existant (Spring IoC) et qu'on change les noms pour éviter le plagiat.
web.xml c'est aussi has been que la configuration Spring en XML. Bientot on va ressortir les .ser des EJB 1.
@Grunt2000 : pour JBOss sur 5 ans tu peux prendre l'option EAP (payante) mais qui te garantie les mises à jour retro compatibles. Sinon avec jboss-modules tu peux justement avoir plusieurs versions de tes jars selon tes applications.
L'implémentation de référence de JAX-RS (qui est Jersey) ne le fait pas, le fait d'utiliser des objets en paramètre de méthode avec une sérialisation implicite en JSON n'est pas un standard JAX-RS. Il est cependant possible d'utiliser des objets personnalisés si ces derniers respectent certaines condition définies dans : documentation §3.2 | Example 3.9, mais il n'y a pas de sérialisation directe en JSON (avec une implémentation Jackson ou autre) comme pour Spring MVC.Citation:
JAXRS le fait aussi : jackson est present dans Resteasy par exemple
Tu avais un provider dès la version 1 de Jersey.
Tu l'as via JAXB donc standard de Java EE: https://jersey.java.net/documentatio...a.html#d0e7963
Tu dois pouvoir écrire ton prope code sur Json-p. Sans compter les autres méthodes non-standard mais qui en réalité fonctionneront avec les autres serveurs d'application.
Bref je trouve cela un 'faux' problème.
Spring et JavaEE apportent une solution très proche aux mêmes problèmes : génération coté serveur, http, gestion de la transaction, mapping objet-relationnel, mom etc. Et ca c'est valable dans toutes les applications à des degrés divers. Après
Chaque pile est composable à volonté : soit en ajoutant des éléments (approche Spring) soit en en retirant (approche Java EE avec les profiles notamment d'ailleurs on notera aussi que tous les serveurs Java EE sont modulaires) mais au final c'est quasiment la même chose et l'approche light container de Spring est aussi lourde que Java EE de nos jours.
Comment expliquer ma vision des choses ?Citation:
Envoyé par Gugelhupf
Le serveur d'application ou Spring, il y a un temps pour l'installer et le configurer. Et puis, il doit s'effacer.
À un moment, la MOA, la direction de l'entreprise, donnent des directives pour que des travaux métiers soient accomplis : des processus, des IHM ou des sites web qu'elles veulent voir mis en place. À ce moment, leur évoquer Spring ou JBoss suscitera leur incompréhension : ce n'est pas le sujet. Le sujet c'est pas quel serveur d'application ou framework a t-on, mais : "Qu'est-ce qu'on fait avec ?".
Des développements informatiques qui se déroulent sur quatre ou huit ans par exemple, si au bout de six mois tu es encore entrain de parler aux gens de JBoss ou Spring, il y a un problème. Les datasources, la sécurité, la définition des files de messages, ça devrait soit être fini, soit ne plus réclamer que des interventions rares et ponctuelles. Si la prégnance du framework demeure, c'est parfois un standalone.xml ou un applicationContext.xml mal finalisé, mais plus souvent des classes qui réclament lors de leur écriture d'exécuter des instructions du framework directement, alors que ces instructions spécifiques là auraient dû être logées dans des classes de base, abstraites ou des modules "système" et ne plus être visibles depuis longtemps.
Après six mois de développement, le sujet ce n'est plus le framework, c'est le boulot métier qu'on fait pour ceux qui nous l'ont demandé. Tu ne peux plus répondre ni à ta direction, ni à tes développeurs : "Il faut être Spring ou pas Spring", parce que tu devrais être passé à autre-chose, à un autre stade de tes réalisations et ne laisser la maintenance et l'évolution de ton framework / serveur d'application au seul Architecte JEE qui en est responsable, et laisser tous tes développeurs strictement sur les sujets métiers.
Et ce que tu écris est révélateur, à mon sens, du problème qu'il y a avec le framework Spring.
C'est que ceux qui le choisissent consacrent trop de temps à faire "du Spring" : à le paramétrer, à en débattre, à l'accroitre, à le transformer, à tourner autour au lieu de s'occuper du sujet principal qui intéresse vraiment l'entreprise : les applications métiers. Elles, ces applications métiers, ne dépendent que :
- De sites web ou IHM lourdes
- De DAO ou autre système pur JPA
- De files d'attentes
- D'un paramétrage de sécurité.
Et ça, c'est parfaitement indépendant (à part le dernier point), du framework / serveur d'application qui se trouve derrière ou en tout cas, peut se considérer sans réclamer de savoir auparavant lequel il sera.
À mon avis, c'est le sens des rapprochements en cours via les JSR : @Inject, @Named qui remplacent petit à petit @Service, @Stateless, @Component, @EJB.... afin d'équarrir cette terminologie doublonne.
Si au bout de six mois de dev on est encore entrain de penser Spring ou JBoss, c'est qu'on a loupé sa mise en place de Spring ou de JBoss, à mon sens.
Si les développeurs doivent faire du Spring ou du JBoss au lieu de faire des DAO, des objets métiers, des services et des pages web, c'est que quelque-chose n'a pas été fini dans l'installation initiale du JBoss ou du Spring.
Je ne vois pas trop où tu veux en venir. Tu dis qu'il faut se concentrer sur le métier au lieu de la technique ? (cf: DAO). Si tu fais de l'informatique, tu dois à la fois maitriser la technique et le métier ainsi que les problèmes et contraintes liés à ces deux concepts, l'un ne va pas sans l'autre, car si tu ne vis que pour la technique tu passeras pour un gros geek, si tu fais mine de ne te focaliser que sur le métier parce que tu n'aimes pas toucher à du code tu passeras pour - excuse moi du terme - un gros branleur. Finalement les JSR ou Spring ne sont qu'un reflet pour apporter une solution aux problèmes techniques existants.
Tu y vas un peu fort !
À un moment donné, il faut tout de même réaliser quelque-chose avec ce que l'on a. Un framework ou un serveur d'application sont un socle pour bâtir quelque-chose dessus, et c'est cette chose bâtie dessus qui a de l'importance pour l'entreprise.
Oublier cela, c'est quand même risquer de se dévoyer.
si tu fais mine de ne te focaliser que sur le métier parce que tu n'aimes pas toucher à du code
Au contraire : c'est quand tu t'occupes du métier que tu fais du code !
Si tu produis des jeux d'écritures comptables d'après des commandes clients, il faut bien mettre le code Java derrière pour qu'elles se fassent. Et le code à écrire, à l'inverse de ce que tu penses, est plus volumineux (normalement) que tout ce que tu auras eu à écrire de Java spécifique à Spring ou JBoss.
un architecte :whistle2:Citation:
Envoyé par Gugelhupf