Anthony Patricio’s Blog

La fin de Spring Framework ? Oui, enfin peut-être

Posted in Actu / Anecdote by apatricio on mars 14, 2012

Depuis quelques semaines nous assistons à une déferlante d’articles annonçant le « retour » en grâce de Java EE, reprenant en force le terrain qu’il avait concédé à Spring. Spring n’a jamais été un concurrent de Java EE, plutôt un complément.

L’histoire se répète

Le cycle observé avec Struts se répète.
On ne va pas entrer dans des détails rébarbatifs mais globalement, concernant Struts

  • J2EE n’est pas efficient pour le web MVC
  • Une personne de talent va créer un framework en dehors de J2EE,
  • bien entendu ce framework ne ré invente pas la roue mais l’optimise
  • ça apporte tellement que le framework est massivement adopté
  • il devient « standard de fait »

A partir de ce moment, il y a 2 chemins possibles. Le premier est de contribuer à normer/spécifier pour Java EE ces avancées, à les intégrer dans le pack normé, en quelque sorte c’est apporter sa pierre à l’édifice. Le second consiste à se battre contre des moulins et s’obstiner à lutter contre la « norme » (on est dans le monde software hein, je parle pas de l’idéologie humaine de la norme à laquelle je n’adhère pas) ou pire tenter de la saboter et je pèse mes mots.

Se battre contre des moulins

D’une façon ou d’une autre, si l’idée brillante d’un cerveau n’est pas dans une spec, elle le sera tôt ou tard, grâce au cerveau à l’origine de l’idée ou non, telle quelle ou optimisée/évoluée/complétée. C’est inéluctable. La spec est bonne car elle ouvre la compétition à diverses implémentations. Car elle permet de ne pas ré inventer la roue. Elle est un repère. Elle résulte de débats impliquant diverses visions.

Plus important à mon sens, une spec est une garantie d’homogénéisation des compétences. Je m’explique. Le développeur qui a fait ses armes avec Hibernate 2 (standard de fait) est passé sans soucis à Hibernate 3 qui lui a ouvert les portes de manière assez transparente à JPA 1.0 puis JPA 2.0. C’est extrêmement intéressant et surtout pérenne en terme de gestion des compétences. Les projets ayant adopté Hibernate 2 en 2004, les SSII ayant misé sur les compétences Hibernate à cette même époque ne s’en rendent pas compte, mais ils ont fait un choix extrêmement profitable.

La personne qui a fait ses armes sur struts a du ré investir (lui ou son employeur) pour s’adapter aux nouvelles technos front web. C’est fâcheux car coûteux mais pourtant inévitable.

Que reste t-il à Spring ?

Spring s’est toujours posé en lévrier agile et pratique face au mammouth que sont qu’étaient les serveurs d’applications. Je dis « étaient » car avec GlassFish puis JBoss AS7 la donne a changé. J’ai développé une appli relativement complète et complexe sous JBoss AS 5 il y a quelques mois. J’avoue m’être vite lassé des temps de redémarrage du serveur. J’ai même très vite employé Arquillian pour mes tests unitaires. Mais maintenant? A quoi bon? JBoss AS7 démarre en 4 secondes avec mon appli déployée (moins de 2 vide). L’emprunte mémoire a été drastiquement réduite. Où est le mammouth? Qui plus est, si je souhaite toujours alléger mes tests j’utilise encore Arquillian et ShrinkWrap mais c’est un autre sujet.

Reste l’argument de dire qu’il y a trop de choses dans Java EE. Est-ce sérieux? Qui vous force à tout utiliser? Personne mais le jour où vous avez besoin d’un élément plus exotique, plus poussé, si Java EE vous le propose, vous l’avez! et il est prêt à s’intégrer dans votre application et votre environnement d’exécution le supportera. Et s’il n’existe pas? Et bien adoptez un framework hors Java EE, je parie un bras que les serveurs d’application sauront le digérer.

A ne pas vouloir intégrer son idée dans Java EE, on finit par réveiller la concurrence. C’est ce qui est arrivé avec Seam qui est venu concurrencer Spring. Seam n’a jamais été une copie de Spring mais permet aussi la conception orientée composants, l’injection des composants, s’appuie de suite sur les annotations (là où Spring les combat initialement) mais aussi l’apport de divers contextes. Les deux framework sont de très bons framework, assez différents en fait mais qui se chevauchent sur une petite région et c’est cette région qui méritait justement une spécification. La vraie grosse différence est que les gars de Seam, ceux de JBoss, sont en faveur des specs et ont ainsi proposé la spec CDI qui est un joli succès. Il faut bien avoir en tête ce que cela signifie. Lorsque l’on part d’un framework isolé, autonome, en dehors de Java EE, se battre pour une spec c’est:

  • exposer son framework « indépendant » à la concurrence de la spécification, c’est bien se tirer une balle dans le pied
  • faire un cadeau à la concurrence en lui permettant d’implémenter la spécification (pour JPA, Hibernate contre EclipseLink par exemple)

Mort? Enfin peut-être, pas si vite coco

Tout ceci semble donc annoncer la mort lente de Spring. Ce n’est pas de violence donc je fais preuve ici mais bien d’objectivité. Je ne pense pas que ma vision soit biaisée par le fait que je bosse pour JBoss, n’en déplaise à mes contradicteurs. Si je devais retrouver un poste plus indépendant de décideur technique, JBoss AS7 s’imposerait car sérieux, rapide, robuste, intégrant beaucoup de ce qu’une entreprise peut avoir besoin pour développer un application. Il y a une petite chance que j’utilise Spring avec JBoss AS7 pour un temps, histoire de voir comment évolue la spec capable de le remplacer (et de faire plus) mais mon but ultime serait l’adoption de chaque spec sérieuse.

Cependant 3 conséquences pour 3 contextes distincts:

  • Les entreprises ayant investi sur Spring vont continuer de le faire jusqu’à ce que les compétences disponibles sur le marché des développeurs sur ces nouvelles specs atteignent en volume les compétences Spring. Ce n’est pas demain la veille mais ça arrivera! Sauf si Spring se ré invente et sort de son chapeau de nouveaux apports flagrants, ce qui n’est pas le cas actuellement. Je ne dis pas que Spring n’apporte rien de plus ou de différent, je dis que ce n’est pas suffisant pour parer le choix Java EE.
  • N’oublions pas le parc d’applis basées sur Spring actuellement en production, peut être pour une décennie voire plus. Il y a encore moult applications basées sur Struts qu’il faut maintenir mais l’on voit bien justement le problème du coût de maintenance de ces applis. Les profils qualifiés en struts ne sont plus si faciles à trouver. Le développeur qui sera motivé pour intervenir sur une appli Struts est une perle rare (ou maso).
  • Enfin se pose la question des nouveaux projets. Un décideur technique ne foncera jamais tête baissée sur une Spec (ou même un Framework) 1.0 et ce même si les exemples de bonnes spec 1.0 sont nombreux. Que choisiront-ils?

Au delà de cela il ne faut pas oublier ce que les gars de Spring ont apporté à Java, énorme respect pour eux ils sont fait avancer le Schmilblick.

Publicités
Tagged with: , , , , ,

Seam 2 et JBoss AS 7

Posted in AS7, Seam, Seam 2 by apatricio on septembre 22, 2011

Cet article n’est que la traduction d’une partie du document https://docs.jboss.org/author/display/AS7/How+do+I+migrate+my+application+from+AS5+or+AS6+to+AS7 de la communauté JBoss.

Migrer vers un nouveau serveur d’applications ou vers une nouvelle version majeure d’un même serveur d’application apporte souvent son lot de contrariétés. Avec JBoss AS 7, c’est le cas même si je trouve personnellement beaucoup moins compliqué de faire tourner ses applications web existantes (on verra pour les EJB avec JBoss AS 7.1 plus tard) que lors de migration précédentes. Si vous tentez de déployer brutalement une application WAR basée sur Seam 2, ça ne fonctionnera pas, vous aboutirez à un problème du type

Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.Log

Lorsque l’on tombe sur un problème de ce type, on se dit que les problèmes vont s’enchaîner et qu’on va y passer des heures, no stress voici les étapes à suivre pour s’en sortir très rapidement, prenons l’exemple d’un WAR.

Pré-requis: assurez que votre source de données est bien configurée dans votre instance d’AS7. Niveau JNDI, choisissez java:jboss/ plutôt que java: pour éviter toute surprise.

  • Se pose le problème de JSF. AS7 contient JSF 2.0 mais Seam 2 tourne avec JSF 1.2. Pour notifier à AS7 que votre application ne veut pas de JSF 2.0 mais requiert JSF 1.2, créez un fichier jboss-deployment-structure.xml dans META-INF et remplissez-le comme suit:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
 <deployment>
  <exclusions>
   <module name="javax.faces.api&quot; slot=&quot;main">
   <module name="com.sun.jsf-impl&quot; slot=&quot;main">
  </exclusions>
  <dependencies>
   <module name="javax.faces.api" slot="1.2"/>
   <module name="com.sun.jsf-impl" slot="1.2"/>
   <module name="org.apache.commons.logging"/>
   <module name="org.apache.commons.collections"/>
   <module name="org.apache.log4j"/>
   <module name="org.dom4j"/>
  </dependencies>
 </deployment>
</jboss-deployment-structure>
  • Vous remarquez de suite que l’on en profite pour régler son sort à commons-loggins ainsi qu’aux autres dépendances qui vous auraient posé problème.
  • Hibernate va lui aussi poser problème. Votre application Seam2 est probablement aussi basée sur Hibernate 3.x, hors AS7 est livré avec Hibernate 4. En théorie pas de problème de rétro compatibilité si ce n’est quelques classes qui ont disparues dans la version 4… oui bon ok c’est un problème de rétro compatibilité. Pour y parer, ajoutez simplement les jars suivants dans votre archive. Pour notre webapp, cela se passe dans WEB-INF/lib et vous trouverez les bonnes versions dans votre distribution de Seam 2 ou dans la version de JBoss AS qui la contenait (JBOSS_HOME/seam/lib)
    • slf4j-api.jar
    • slf4j-log4j12.jar
    • hibernate-entitymanager.jar
    • hibernate-core.jar
    • hibernate-annotations.jar
    • hibernate-commons-annotations.jar
    • hibernate-validator.jar
    • mais aussi gwt-servlet.jar, … selon ce que vous utilisez de Seam 2
  • Un dernier soucis lié à AS 7.0.1 subsiste quant à JNDI,
    • dans persistence.xml , soyez sûrs de définir jboss.entity.manager.factory.jndi.name dans java:jboss/ et non java: (ceci devrait être corrigé très prochainement)
    • dans components.xml , idem pour <persistence:managed-persistence-context/>
  • redeployez votre war (s’il est explosé, touch mywar.dodeploy)
Cela devrait fonctionner.
Tagged with: , , , ,