1. ESB in Financial Application

2. Objectif de la présentation

En quinze minutes, l’idée de cette présentation est d’expliquer les besoins rencontrés dans le monde de la finance en terme d’architecture. Où en sommes-nous aujourd’hui et quels outils pouvons-nous utiliser afin de réduire les coûts et améliorer nos architectures ?

3. Speaker’s Qualifications

Après 5 ans 1/2 chez Reuters, j’ai débuté une nouvelle activité en tant qu’indépendant. Je travaille actuellement chez BNP-Paribas sur une mission d’architecture. Je suis membre du Paris Java User Group.

4. ESB

ESB. Ce mot est à la mode. A Devoxx j’ai compté 4 conférences cette année. Mule est traité 3 fois par Antoine Borg avec qui j’ai eu le plaisir de discuter la veille, bref il se passe quelque chose. A noter qu’aucune conférence ne nous parle de téléphone portable, les thèmes cette année tournent autour de l’intégration, de la sécurité ou de SOA. Voyons un peu « dans la vraie vie » où nous en sommes aujourd’hui, car moi, plutôt que de parler de SOA ou d’ESB, j’aime bien parler du terrain avant tout.

5. A legacy application

Ce que l’on constate c’est que les applications vieillissantes dans le monde Java des applications de gestion et de la finance, se présentent avec un socle d’architecture bien connu. Autour d’une architecture trois-tiers, nous retrouvons souvent du Struts pour la partie Web, un serveur d’application avec encore beaucoup d’EJB 2.1, et les innovations des dernières années que sont Hibernate, Spring et JMS. Et il est clair que ce type d’architecture aujourd’hui en production est encore amené à perdurer pour quelques années.
Votre travail sera donc de faire vivre, d’améliorer ou de transformer ce type d’architecture.

6. A legacy application (cont.)

Dans la finance, une application web communique et échange des ressources avec le monde extérieur en utilisant un certain nombre de connecteurs techniques (boîtes vertes). Ce code est bien souvent du code développé au fur et à mesure des besoins. Il peut s’agir de lire un fichier, d’échanger via JMS avec une autre application, de faire appel à un web service, ou d’envoyer un email. Bref, du code massivement technique. Ce code est le socle de communication de chaque application de gestion.

7. Connect

Connecter.
Le besoin de Connecter différents systèmes. Ce besoin entraine un travail de médiation, de transformation et d’interconnexion entre systèmes. Je veux montrer ici qu’il y a forcément un besoin de connexion, au minimum avec une base de données relationnelles, mais bien souvent avec d’autres systèmes informatiques ou techniques. C’est une composante fondamentale de nos solutions, de ce que nous sommes appelés à développer.

8. Ecosystem

J’ai représenté sur ce slide une application financière typique de création de rapports, utilisé sur une plateforme de Prime Brokerage. Ce que nous voyons tout d’abord, c’est que cette application a besoin d’un environnement pour fonctionner, un écosystème. Cet écosystème est composé d’un grand nombre d’applications, maintenu par d’autres équipes que la mienne.
Mon application est représentée au milieu avec ses 3 services internes.

9. Ecosystem 2

Cette application utilise les données du marché ainsi qu’un service de tenue de Position. Aujourd’hui les échanges entre les systèmes s’effectuent avec des fichiers plats via des répertoires partagés ou via JMS. Dans le livre Enterprise Integration Pattern, une excellente présentation explique les avantages et les inconvénients de ces 2 types d’échange.

10. Ecosystem 3

Au delà des échanges de mon application, ce qui est encore plus intéressant c’est de constater que les autres applications échangent elles-aussi des informations entre elles. Il faut donc bien voir que nous sommes là face à un vrai réseau de communication, de médiation et d’échanges. C’est le coeur d’une architecture financière.

11. Ecosystem 4

Au final je dois prendre en compte que mon application cohabite, échange et transfert ses données avec un nombre assez important d’applications. Je ne rentre pas dans les détails de la partie métier, car l’idée ici n’est pas de vous donner un cours de finance des marchés, simplement d’expliquer que les systèmes sont massivement connectés en un réseau.

12. Ecosystem 5

… En forçant un peu le trait, je peux faire une analogie avec un réseau social comme FaceBook : mon application fait partie d’un réseau, d’autres applications m’envoient des messages, observent même les données que je produis sans que je ne le sache, il y a donc clairement un besoin important à résoudre : ce besoin de communication et d’échanges avec mes « amis ».

13. Collaborate

Collaborate en anglais, difficile à traduire avec le même sens en français.
Collaborer c’est apprendre à se connaître : lorsque mon application échange avec d’autres systèmes financiers, au delà du problème technique à résoudre il y aura une interaction humaine. Et donc, ESB ou non, SOA ou non, ce projet d’inter-communication doit s’accompagner de la définition d’une langue pour se comprendre, d’un média pour discuter et d’un contenu pour s’entendre.
Revenons un peu à notre application financière type pour parler d’un facteur très important : le temps.

14. Timebox and Adaptive

J’ai sélectionné ces deux photos du métro afin d’illustrer un facteur important dans les applications financières : l’importance de l’heure de la journée. Prenons le métro de Paris : le matin entre 07h00 et 09h00 il y a un métro chaque minute. A 14h il y a un métro toutes les 6 minutes. A 23h00 il y a une rame toutes les 15 minutes.
Le nombre de rame de métro par heure s’adapte selon les heures d’affluence.
Qu’en est-il de mon application financière ?
Chaque matin celle-ci a besoin de 10 fois plus de puissance qu’en pleine journée, car la génération des rapports doit s’effectuer à la fermeture du marché boursier, dans un intervalle de temps limité. Il n’est pas possible de lancer la génération tant que le marché est ouvert. D’autre part celle-ci doit s’effectuer avant l’ouverture du marché suivant, en Asie. De fait, nous nous retrouvons avec une architecture qui doit répondre à des demandes fluctuantes selon l’heure de la journée.
Mais le plus important est que notre application n’a pas le droit à une deuxième chance. Lorsqu’un bug survient, il faut que l’erreur soit corrigée avant l’ouverture du marché, et ce phénomène n’est pas contrôlable.
Enfin on constate que passé les quelques heures d’activité, la plateforme est ensuite peu sollicité en cours de journée.
Or le souci, c’est qu’aujourd’hui mon architecture n’est pas écologique : 16 serveurs de calcul de risk tournent en permanence, 4 serveurs d’applications sont sollicités pendant la journée mais l’utilisation des ressources est assez inégale durant la journée.
Il faut donc retenir que dans la finance, l’utilisation des ressources et la quantité des échanges avec les autres systèmes varient au cours de la journée. Cependant nous savons à l’avance nos besoins, et donc idéalement notre système devrait pouvoir s’adapter et se programmer comme le réseau de transport parisien.
Un site internet qui vend des ordinateurs pourrait être surpris de l’affluence de visiteur. Pas une application financière : il est possible de connaître à l’avance les besoins en énergie. Mais pourtant, il est difficile aujourd’hui de régler et d’adapter cette énergie.

15. Crisis

2008 marque le début d’une crise financière, qui aura un impact dès demain sur les budgets des projets dans le monde de la banque et de la finance. Nos besoins de connexions avec les autres applications financières demeurent. Je pense même qu’il y aura de nouvelles réglementations pour éviter certains dérapages de 2008. Vu la nervosité des marchés financiers, les calculs de VaR, de risque, d’appel de marge, de collatéral sur notre application de Prime Brokerage vont aussi certainement être plus intensif… Bref il va y avoir du sport en 2009.

16. Predictions for 2009

ll est donc facile d’imaginer ce qui nous attend : avec moins de budget, moins de liberté et plus de pressions, il va falloir trouver des solutions rapides, économiques et capables de faire réaliser des économies. Pour ma part, un calcul de risque c’est un appel de marge pour un client. Si la plate-forme sur laquelle je travaille peut traiter 50 000 calculs au lieu de 10 000 car mon architecture évolue, alors je ferai gagner de l’argent à mon client.
D’autre part, vu la morosité et la crise du secteur de la finance, je pense que les solutions pragmatiques seront les gagnantes de 2009. J’ai peur que de gros projets basés sur les ESB des constructeurs souffrent du même phénomène que les constructeurs automobiles. Les gens veulent une voiture ? ils achètent une Logan et pas le dernier 4×4 à la mode.
Votre application a besoin d’un ESB ? Peut-être que Spring Integration, Mule ou Apache ServiceMix seront suffisants pour vos besoins, que les gros projets sur 6 mois auront plus de mal en 2009 à être validé par les DSI. Il est temps d’être pragmatique et d’arrêter de rêver sur des besoins que les grands éditeurs d’ESB nous ont peut-être inventé, comme les éditeurs de serveur d’app en 2000… Etre pragmatique, économe, écologique, réaliste.

17. Toolbox

En 2009 je pense que vous lirez des articles, que vous testerez, que vous entendrez parler de ces produits : Mule, Apache Service Mix, Apache Camel, Spring Integration, OpenESB project Fuji, Apache Synapse, Apache CXF, Jboss ESB… car ce sont des solutions qui répondent à un besoin : l’intégration légère en entreprise.
Après la guerre des serveurs d’application il y a quelques années, je pense que la prochaine grande bataille sera sur ce front. Les éditeurs du monde open-source savent que la demande va exploser, car lorsque la crise est là comme en 2001, le monde open-source tire son épingle du jeu. En 2002 personne ne se souvient mais c’était la grande époque des articles sur Linux dans 01 informatique, le Monde informatique ect. L’administration français a alors fait un grand pas en sélectionnant des solutions comme JBoss Application Server pour traiter… nos déclarations de revenus.
Economies, pragmatismes, simplifications, réductions des coûts…

18. A New Approach

Alors si nous repensons à notre application de gestion du début, voici comment je la vois en 2009. Tout d’abord le Web tiers a été déporté de mon architecture. Je ne fais pas une application Web, je fais d’abord l’architecture d’une application de gestion. Le web ne me coûte pas cher, j’utilise des frameworks légers sur une recopie en lecture seule de ma base de données. Seule une petite partie du code métier est partagée avec mon espace de données principal.
Ensuite on voit que j’ai cassé ce gros rectangle : je pense que des services sans états et légers sont suffisants pour effectuer les traitements de mon application. Là où auparavant j’utilisais la base de données pour stocker des données de travail, j’utilise désormais un espace mémoire en cluster afin de répliquer les données nécessaires à mes traitements de calculs. Cela demande plus de mémoire physique mais quintuple les performances de traitements. La base de données relationnelle n’intervient que via un service d’historisation qui effectue des captures de données afin de sauvegarder les données les plus sensibles, essentiellement pour un problème légal. Notez que la base est un petit carré bleu, car finalement elle ne me sert plus à grand chose.
Ces services reprennent la boîte à outil dont nous avons parlé tout à l’heure. Plutôt que de chercher à faire une grosse boite qui fait tout (un ESB au sens de certains) je crée un ensemble de services qui discutent et s’échangent des données. Et plutôt que de tenter de résoudre les problèmes de communication avec les applications extérieurs, de tenter de mettre en place un gros chantier afin de mettre tout le monde sur la même plateforme, je conserve et respecte les systèmes extérieurs, je m’adapte à eux, eux ne s’adaptent pas à moi. Et là je sais que mon application pour 2009 pourra continuer à exister sans couter une fortune.
Il faut donc oublier ce rêve qui serait de migrer toutes les applications de mon réseau vers un seul et même système. Ce serait un risque si l’éditeur disparaît (ce qui n’est pas exclu en ce moment). Ce serait la plus belle décision pour dégrader massivement les performances : pourquoi un système extérieure serait plus rapide que ce que mes équipes ont développé ? Ce serait un risque technique, un risque en terme de sécurité, et finalement, il faudrait attendre 6 mois avant de voir ce type de projet de gouvernance sur les rails.

Pour revenir à l’image du métro parisien, je rêve aussi de louer de la puissance machine plutôt que de l’acheter en utilisant par exemple Amazon EC2 et une solution comme Elastic Grid pour piloter mon parc informatique. Pour cette raison mon nouveau système est découpé en services sans état afin de faciliter une migration partielle et rapide de certains services vers ces nouvelles plate-formes de calculs et d’hébergement. La première banque qui aura déployé une plateforme de calcul de risque hostée comme un service sur internet gagnera certainement beaucoup d’argent.
Economies, pragmatismes, simples, réduire les coûts, arrêter de croire au père noël, pensez sur 6 mois…

Code code code
Ensuite j’ai un slide technique pour montrer un exemple d’utilisation d’Apache Camel. Lors de la conférence je n’ai pas eu assez de temps pour les présenter. Je vous ferrai un article complet sur Camel prochainement, donc revenez en janvier pour voir la suite.

Keep it simple

Pour connecter plusieurs systèmes il est tentant de faire n’importe quoi, de faire au plus vite ou de chercher une solution chère et trop complexe pour un problème. Soyez simple et vous réussirez à développer une architecture qui fonctionne.

Ne pas faire de l’intégration pour en faire…
Comme ces messieurs dans la piscine : ne cherchez pas à faire de l’ESB pour en faire, et faites attention à votre environnement. Un ESB ne remplace pas une réunion de pilotage avec l’autre équipe en face qui fait « l’autre » produit.

Don’t buy a solution

N’achetez pas les yeux fermés une solution. Au contraire, il faut que vos équipes retroussent leurs manches, repensez à des solutions simples. Dans le monde des applications de gestion, et de la Finance, le temps est certes à l’économie, mais aussi à un pragmatisme souvent contraire à nos envies d’architectes et de consultants.

The End

En conclusion : nous avons discuté des besoins en architecture dans le monde de la finance : connecter, échanger et collaborer, inter-agir avec d’autres systèmes. Les solutions d’intégrations légères seront en 2009 un moyen de réduire les coûts en évitant d’écrire à la main du code technique sans valeur ajoutée. Je souhaite dépiler un message JMS et envoyer un email, Mule m’aide à le faire en quelques heures au lieu de perdre mon temps avec du code sans valeur. Face aux réductions de budgets, il est logique de penser que les solutions d’intégration dans la finance auront le vent en poupe en 2009. Et face à cette crise, il y aura encore plus de travail pour nous, avec encore moins de budgets, d’où la nécessité de s’outiller enfin correctement.

Fin de la présentation
————————————————

Which application server you use?

Petit sondage sur l’un des tableaux blancs installés au premier étage. Avec l’appareil photo de l’iphone mes photos étaient toutes plutôt ratées. J’ai trouvé sur flickr une image d’un des tableaux qui m’a valu une bonne discussion là-bas lorsque j’étais devant avec d’autres développeurs.

Voici le nombre de résultat par serveur d’application:

• - JBoss Application Server : 136 voix
• - Oracle WLS + BEA Weblogic : 75 voix
• - GlassFish : 78 voix
• - IBM WebSphere : 46 voix (j’adore « web fear »)
• - Plain Tomcat, Jetty, Resin : 148 voix
• - Geronimo : 5 voix
• - Spring App Server : 7 voix
• - SAP Application Server : 2 voix
• - JONAS : 3 voix

Bref avec Spring dm Server qui arrive sur ce marché, je pense que nous allons voir l’an prochain des batailles de discussions sur « mon mien il est meilleur que ton tiens » comme il y a quelques années…

Cela promet des heures de discussions sur les blogs.

En première partie, Sacha Labourey le CTO de JBoss, une division de RedHat effectue une présentation sur JBoss AS 5.0. En deuxième partie, présentation de JBoss Seam par Malik Saheb. Le tout devant 200 personnes, la salle étant comble comme la fois précédente.

Sacha Labourey présente d’abord un petit historique de JBoss Application Server. A ses débuts en 2000 la volonté des développeurs est de proposer un serveur d’app plus léger, avec la possibilité de recharger à chaud une application sans relancer le serveur. Pour cela l’architecture du micro-kernel basée sur JMX permet de gérer le chargement des ressources d’une application. J’en ai parlé en 2006 lors de ma formation à JBoss à Berlin. 4 articles du touilleur vous donneront un petit aperçu du moteur de JBoss si vous souhaitez vous faire votre propre idée.

Sacha enchaîne ensuite avec une justification sur la prochaine version de JBoss, JBoss AS5. En ligne de mire, la certification EE5, une infrastructure plus souple et plus puissante pour le clustering, une offre de messaging qui ne sera plus basée sur JBoss MQ mais sur JBoss Messaging, une réécriture de la couche Web Services avec les dernières innovations de JEE 5.

L’un des objectifs de JBoss Application Server 5 est de s’affranchir du kernel basé sur JMX. Là où il y a quelques années, JMX était la solution pour connecter différents modules, aujourd’hui entre OSGI et l’injection de dépendances, Sacha explique que le nouveau moteur est basé sur des POJOs, accompagnés d’annotations. C’est donc un énorme travail de réécriture et de migration de code qui a entrainé le retard de la sortie de JBoss AS 5.

Quand sort JBoss AS 5 GA ?
Si l’on regarde JBoss 5, cela fait 3 ans que ce chantier a été lancé. La sortie est prévue dans les semaines qui viennent, vraisemblablement avant Noël. Le temps passé à écrire cette nouvelle version permet d’offrir une version plus mature de JBoss. Il faut se souvenir qu’il y a presque 3 ans, JBoss AS était l’un des premiers serveurs à offrir le support des EJB3 en l’état. La RC2 de JBoss AS 5 a été certifiée EE5 début septembre.

Parmi les nombreuses nouveautés que Sacha nous présente dans ces slides, j’ai noté une nouvelle API de configuration, un nouveau moteur d’injection, une gestion des aspects, et beaucoup d’autres fonctionnalités.

OSGI ?
Sacha explique qu’OSGI ne donne pas tout. Il n’y a pas de gestion de classe unique, ni de gestion des méta-données. Enfin même si OSGI permet le rechargement partiel d’une application, il n’y a pas la notion de graphe d’état :INITIALIZING, RUNNING, STAND-BY…

A la question « mais où est le marché pour ces besoins ? » la réponse est assez floue. Là où Spring dm Server nous promet de répondre à des soucis que nous n’avons pas encore, je pense que JBoss passe encore une étape supplémentaire vers le « on n’en n’a pas besoin mais c’est intéressant »…

J’ai ensuite bien aimé une partie de la présentation de Sacha, qui est un orateur très intéressant et qui a vraiment séduit le public du JUG. Il explique par des chiffres le fait suivant : les éditeurs de serveur d’application J2EE se réduisent de version en version.
– sur Java J2EE 1.2 : 18 serveurs d’application différents
– sur la version 1.3 : 22 serveurs d’app
– sur la version 1.4 : 17 serveurs d’app
– sur la version EE5: 10 serveurs d’app
– sur la future EE6 : 7 (IBM, Oracle, SUN, SAP, NEC, Kundlee et ITMakeSoft)

Vous notez comme moi l’absence de Spring. Va savoir pourquoi.

Comme Sacha l’explique, le marché des serveurs d’application est maintenant mature, d’où cette consolidation. La guerre est terminée. Quoique…

Il présente ensuite la démarche de RedHat. JBoss AS est, et restera open-source. La politique de licence n’a pas changée. Open-source et open-standard. La version Enterprise offre une version industrielle indispensable pour mettre en production une application. Il est utopique de penser qu’aujourd’hui un client final met en production une version sans prendre du support. Ceci non pas pour des raisons techniques, mais avant tout pour des raisons… légales. Thomson-Reuters où j’ai travaillé 5 ans 1/2 a signé un partenariat avec RedHat afin que les versions des produits basés sur JBoss comme KGR s’appuient sur le support de RedHat en cas de problèmes avec JBoss AS… afin d’assurer les clients finaux de la pérennité du socle technique.
La version enterprise est supportée pendant 3,5 ou 7 ans. Les versions sont testées de manière intensive, et le support basé à Neuchatel permet à RedHat d’offrir une qualité de service indispensable aux équipes de production. J’ai eu le plaisir de discuter avec Luc Texier que j’ai déjà rencontré en juin 2006, à propos du support et du travail de RedHat.

La version Enterprise Application Platform (EAP) est strictement identique à la version open-source de JBoss, JBoss Application Server.

EAP offre en plus d’autres outils pour les équipes de production comme JBoss ON, outil de supervision et de monitoring. Pour les esprits grincheux, il existe aussi JOPR, outil libre et open-source qui est l’ancien JBoss ON, fruit d’un travail commun avec Hyperic.

Sacha Labourey présente ensuite avec différents slides l’architecture de JBoss AS 5. C’est assez technique et trop long à raconter ici. Je retiens simplement l’ajout d’un Virtual FileSystem qui permet de créer virtuellement un EAR lors des tests par exemple.

Les questions de l’assemblée tournent autour d’OSGI, des synergies entre les équipes de RedHat et les équipes de JBoss. Quelqu’un demande pourquoi ne pas standardiser le micro-kernel de JBoss ? Sacha répond que si la demande de la communauté est là, ils y travailleront. Il rappelle qu’Hibernate est sorti avant JPA, que Seam est disponible depuis 2006 et une partie de Seam est maintenant une JSR, la JSR WebBeans. Donc la démarche est plutôt : utilisons la technologie puis ensuite regardons comment en faire un standard.
Contrairement à Spring, il dit clairement que pour lui les standards ont quelque chose de bien, ils évitent le syndrome « vendor-lock ». Je vous laisse apprécier son point de vue, que je partage en partie.

A une question sur « mais pourquoi autant de retard sur AS5 ? » il explique que la réorganisation du code source avec des équipes réparties dans le monde ne facilite pas ce travail. Imaginez que le noyau Linux décide de changer de la version 2.6.0.1.2.3.4.3402.beta1 à une version 3.0….

Enfin Sacha donne 2 informations intéressantes :
– regardez le blog de Bob McWhister’s http://oddthesis.org/ qui vous donne des nouvelles sur les discussions et les recherches de Bob
– mod_cluster est un connecteur http dont Sacha parle sur son blog. Je reprends ici la présentation de mod_cluster

mod_cluster is an httpd-based load balancer. Like mod_jk and mod_proxy, mod_cluster uses a communication channel to forward requests from httpd to one of a set of application server nodes. Unlike mod_jk and mod_proxy, mod_cluster leverages an additional connection between the application server nodes and httpd. The application server nodes use this connection to transmit server-side load balance factors and lifecycle events back to httpd via a custom set of HTTP methods, affectionately called the Mod-Cluster Management Protocol (MCMP). This additional feedback channel allows mod_cluster to offer a level of intelligence and granularity not found in other load balancing solutions.

Within httpd, mod_cluster is implemented as a set of modules for httpd with mod_proxy enabled. Much of the logic comes from mod_proxy, e.g. mod_proxy_ajp provides all the AJP logic needed by mod_cluster.

En conclusion, présentation sympa de la part de Sacha dans des conditions inhabituelles : problème de vidéo projecteur, d’ordinateur, d’écrans au fond ne fonctionnant pas… Chapeau pour avoir animé la présentation et réussi à faire passer le message : venez voir JBoss Application Server 5.0

JBoss Seam

Tout d’abord parlons du fond : présentation organisée par Malik SAHEB du framework léger d’assemblage, Seam. Malik est un senior solution architect qui vient du « back ». Il nous explique qu’il va présenter JBoss Seam d’un point de vue technique, en parlant de son expérience. Comme il le dit lui-même il vient du côté obscur, il a travaillé sur le moteur transactionnel de JBoss et sur les EJBs. Le monde du Web était donc pour lui un challenge.

Le constat est le suivant : JSF simplifie l’écriture d’application Web. Cependant il reste encore beaucoup de XML et de code technique pour accéder aux objets métiers et aux EJB3. Seam se propose dans un premier temps de simplifier le travail du développeur en apportant un moteur d’injection basé sur les annotations Java 5. Il évite d’ajouter des composants intermédiaires entre la vue et le modèle.

Ensuite Seam est un framework d’assemblage, qui offre et simplifie au développeur un socle technique assez impressionnant :
– AJAX, JSF, api RichFaces et IceFaces
– EJB3
– JPA
– BPM

Je vous donne l’adresse de la RefCard que Malik nous a présenté : Core Seam 2.1. La lecture de cette carte vous donnera une présentation complète et solide sur le coeur technique de Seam.

D’un point de vue fonctionnalité, Seam offre différents outils simples comme la génération de PDF, l’envoi d’email, l’internationalisation, la gestion du bouton back, de l’history, de REST, l’intégration de Wicket, de Spring, bref vous l’aurez compris : c’est un bus où tout le monde se trouve embarqué afin de faciliter l’écriture d’application.

Seam c’est ensuite des concepts novateurs comme l’introduction de deux scopes dans le domaine des applications Webs : le scope « Conversation » et le scope « Business ». J’en ai déjà parlé sur le touilleur, je vous redonne le lien afin de vous laisser lire cette partie tranquillement.

Seam c’est aussi un ensemble d’outils basés sur maven2 destiné à faciliter l’écriture et le démarrage d’une application. Tout comme Grails, Seam offre depuis 2 ans des outils pratiques pour créer une Entity avec ses pages CRUD, le tout en utilisant JSF+Ajax+une api comme RichFaces ou IceFaces. A noter que le support de GWT s’effectue aussi sans soucis, car Seam s’occupe de la partie serveur, là où GWT travaille sur votre poste.

Il y a aussi quelques fonctionnalités très bien intégrées comme la Validation (JSR-303) ou Hibernate Search, ce qui évite toujours de réinventer la roue.
Enfin Seam a aussi son moteur d’injection de dépendance et d’outjection… Un concept qui vous permet de replacer dans la session, dans la conversation ou dans le scope business un objet Seam. Si vous voulez, c’est un moyen très pratique pour gérer la persistance fine, au delà de la session HTTP qui reste assez pauvre. Dommage c’était très mal expliqué…

… et là mon cahier de note s’arrête …

Je suis sorti à la fin. Honnêtement, je vais me lâcher : présentation complètement ratée. Désolé Malik si tu lis cela, mais il y a plusieurs griefs que je vais justifier. Les gens qui lisent le touilleur savent très bien que je suis un fan de Seam, donc on est d’accord que je ne parle que de la forme et pas du fond de la présentation.

Sur la forme : pas de chance avec ce @#$ de vidéoprojecteur, il était impossible de lire correctement les exemples de code. Et là je parle de ma pomme, assis à côté de David qui filmait pour le JUG la session. Vraiment il faut peut-être revoir le template du Paris JUG et basculer sur un template avec un fond noir et du texte blanc, comme Devoxx. A tester au prochain JUG.

Ensuite Seam est un framework qui ne se démontre pas en listant ses fonctions, ce qu’il propose et s’il fait la pluie ou le beau temps. En tant que développeur j’aurai vraiment aimé avoir une présentation partant d’un cas concret, afin que pendant l’heure je puisse me faire ma propre idée de ce que je pourrai faire ensuite avec Seam. C’est un format plus adapté je pense pour faire passer le message.

Enfin carton rouge pour pas mal de points : je n’ai pas entendu le nom de la personne qui a initié le framework Seam. Dommage car je pense que l’assemblée aurait aimé entendre que Gavin King, monsieur Hibernate, est l’auteur de Seam. Mince c’est pas un truc que l’on oublie de dire.

J’aurai aimé aussi avoir une présentation de quelques minutes sur la différence entre Seam et la JSR-296, Web Beans, toujours initiée par le même Gavin King. Cela aurait mis en avant les éléments couverts par Seam, qui travaille sur un scope plus large que la spec JSR-296.

Bref très déçu, j’ai peur que l’assemblée présente n’ait plus/pas envie d’aller tester Seam.

Alors je pense qu’il faudra en remettre une couche, c’est pour cela que je suis motivé pour vous refaire une présentation sur le blog, à la mode de ce que j’ai envie de vous raconter.

Donc stay tuned.

Conclusion
Soirée au final sympa. Au Paris JUG nous croisons toujours pas mal de monde, c’est l’occasion de faire des rencontres et de voir ou revoir de nouvelles têtes. J’ai bien discuté avec Thomas Parle de Prima Solutions, nous avons aussi parlé beaucoup avec David Dewalle.

Enfin il est important que les sponsors continuent à apporter au Paris JUG toute l’énergie financière nécessaire afin que le JUG continue dans de bonnes conditions. David ne pensait pas qu’en 3 mois le JUG passerait de 30 à 200 personnes chaque mois…

Voilà pour mon compte-rendu, pas eu envie de vider mon sac hier soir tard et de me lancer sur l’écriture d’un long billet. Donc là vous avez la version courte… à peine 2240 mots. Une paille..

A la semaine prochaine à Devoxx !!!

Des articles plus ancien sur JBoss Seam du Touilleur :
– Convertissez vous à JBoss Seam mes frères
– JBoss Seam 2.0 premiers tests
– JBoss Seam : l’intérêt du scope CONVERSATION
– Installer JBoss Seam (article sans doute dépassé)
– Présentation de Luc Texier de JBoss au PJBUG

J’ai un peu de mal avec l’affirmation ci-dessus. Tout d’abord Jboss est un sponsor de Tomcat depuis 3 ans, Mladen Turk a écrit le module APR qui permet de faire fonctionner Apache avec un serveur Tomcat, et il fait partie de l’équipe JBoss. Enfin la version JBoss Web est une version avec support JBoss qui est composée d’Apache et de Tomcat, justement utilisé par nous, gentil contribuable, lorsque nous effectuons notre déclaration d’impôts. Il serait intéressant d’avoir le retour d’une personne du ministère des finances ou de JBoss pour nous éclairer là-dessus.

Aujourd’hui il serait dommage de passer à côté de Spring, de la puissance de l’inversion de contrôle et de la souplesse de ce framework. Avant tout, pour moi, c’est un framework d’assemblage. Il ne m’offre pas de solution de mapping object-relationnel. En même temps, j’ai le choix d’utiliser librement Hibernate, TopLink ou autre. La première chose qui me séduit c’est que je n’enferme pas ma solution dans une architecture compliquée, sans possibilité d’évolutions. Je détache mon produit des griffes des éditeurs comme BEA ou IBM. En effet aujourd’hui, nous payons une fortune des accords OEM, qui, je le dis sans problèmes, ne me servent à rien. Même le support ne sert à rien… Il est payé par le client final qui achète la solution. Mais quelque part, j’ai un peu de mal à me dire que j’engraisse un éditeur avec une rente viagère, le temps que l’architecture J2EE basée sur les EJB 2.1 s’arrête d’exister… On en est là aujourd’hui.

SpringSource, l’entreprise, est devenu une entreprise qui doit maintenant monétiser Spring. Cela passe par des formations, des certifications, du support d’architecture. SpringSource va sur le même chemin que JBoss Inc., l’entreprise. Le support de JBoss est indispensable à nous, éditeurs de logiciels. En effet sans l’existence de la societé JBoss et d’un accord entre ma societé et JBoss, nous ne pourrions pas vendre nos produits à nos clients.
Tout simplement.

Donc en terme de « faut-il un SpringSource… » si demain nous avons des produits architecturés sur Spring, il sera obligatoire pour nous, en tant qu’éditeur, d’aller taper à la porte de SpringSource afin de mettre en place un accord.

La difficulté que je vois, c’est que JBoss offre plusieurs produits, SpringSource offre un framework d’intégration pour grouper plusieurs technologies. Il y a cependant des projets 100% Spring qui sont vraiment biens, à mon sens. Mais on ne peut pas imaginer que Spring va réécrire un moteur de persistence, de transactions ou de sécurité. Spring est avant tout un outil d’assemblage très fléxible. Du coup, lorsque nous envisagons le support, qu’allons-nous vraiment couvrir ? Lorsqu’un client signale un bug, comment identifier ce qui est Spring de ce qui est Hibernate ?

En conclusion donc, il est intéressant de suivre ce qu’il va se passer autour de Java EE 6 et de la position de SpringSource et de JBoss. Il n’y a pas de compétition entre les 2, mais même s’il y avait un embryon de compétition, c’est toujours bon pour le business…

Rappel rapide sur la sérialisation en Java: dans le domaine de la programmation, du stockage de données et de la transmission par le réseau, la sérialisation consiste à sauver un objet Java au format binaire. Il est ensuite possible de transmettre cette objet via le réseau, ou de le sauvegarder sur le disque par exemple. Les données binaires respectent un format spécial qui permet à Java de recréer un Objet identique avec le même état que l’original.En anglais, sérialiser un objet se dit « marshalling » et le désérialiser se dit « unmarshalling ».

Avant tout, certains objets en Java ne sont pas sérialisables: Socket, Thread, OutputStream ou Image par exemple. Cela peut poser un problème à votre application: que se passe-t-il si votre code contient une instance de l’une de ces classes non sérialisable ? Java vous le signale avec l’exception java.io.NotSerializable. Il existe cependant des solutions à ces problèmes.

La sérialisation par défaut

Pour persister un objet à l’exécution, nous devons le rendre sérialisable. Java fait appel à un design pattern appelé « Marker ». Ce design pattern consiste à créer une Interface java vide sans méthodes afin de marquer une class Java comme étant capable d’effectuer un certain traitement. J’aime bien demander en entretien d’embauche: « Peut-on avoir une Interface sans méthodes, sans instances ? Si oui, à quoi cela sert-il ? »

Prenons une class SoccerPlayer qui vient de mes cours sur java:

import java.util.Date;
import java.io.Serializable;

/**
 * Created by IntelliJ IDEA.
 * User: nicolasmartignole
 * Date: 22 janv. 2008
 * Time: 23:07:31
 */
public class SoccerPlayer implements Serializable {
    private String name;
    private Date birthDate;
    private int number;

    public SoccerPlayer(String name, Date birthDate, int number) {
        this.name = name;
        this.birthDate = birthDate;
        this.number = number;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public Date getBirthDate() {
        return birthDate;
    }

    public void setBirthDate(Date birthDate) {
        this.birthDate = birthDate;
    }

    public int getNumber() {
        return number;
    }

    public void setNumber(int number) {
        this.number = number;
    }
}

En marquant notre classe avec l’interface java.io.Serializable, celle-ci est prête à être sérialisée. Nous allons écrire un peu de code pour tester en l’état la sérialisation de cette class.

import java.util.Locale;
import java.text.DateFormat;
import java.io.FileOutputStream;
import java.io.File;
import java.io.ObjectOutputStream;

/**
 * This class marshalls the SoccerPlayer class to a file.
 * User: nicolasmartignole
 * Date: 22 janv. 2008
 * Time: 23:11:07
 *
 * See online Touilleur Express http://www.touilleur-express.fr
 */
public class FileSystemStorageEngine {
     private static DateFormat df = DateFormat.getDateInstance(DateFormat.SHORT, Locale.FRANCE);

    /**
     * Creates a new player, performs a serialiation test.
     * @param args is cl args.
     * @throws Exception for any Exception, I don't want to deal with it in my sample.
     */
    public static void main(String[] args) throws Exception{
        SoccerPlayer player = new SoccerPlayer("Nicolas Martignole", df.parse("24/09/1975"), 10);
        FileOutputStream fos=new FileOutputStream(new File("test.ser")) ;
        ObjectOutputStream out=new ObjectOutputStream(fos);
        out.writeObject(player);

    }
}

La class ObjetOutputStream est la classe qui se charge de sérialiser notre class SoccerPlayer vers le fichier. Si la class SoccerPlayer n’était pas marquée avec l’interface Serializable, Java lève une « java.io.NotSerializable » exception. La class SoccerPlayer est simple, et ses variables d’instance (une String et une Date) peuvent être sérialisées par Java sans problèmes.

Désérialiser

La désérialisation s’effectue en utilisant la class ObjectInputStream. Dans l’exemple ci-dessous, je relis le fichier test.ser et je vais afficher le nom du joueur dans la console.

Nous modifions un peu notre class afin d’appeler une méthode chargée de désérialiser notre fichier. Dans mon exemple je ne fais aucuns traitements d’erreur, et donc si le fichier n’existe pas le programme lévera une FileNotFoundException. Maisi ici le plus important c’est juste de montrer qu’il est simple de recharger un Objet Java en mémoire.

    public static void main(String[] args) throws Exception{

        SoccerPlayer loaded=reloadSoccerPlayer();
        System.out.println("Soccer player name: "+loaded.getName());

    }

     private static SoccerPlayer reloadSoccerPlayer() throws IOException, ClassNotFoundException {
        FileInputStream fis=new FileInputStream(new File("test.ser")) ;
        ObjectInputStream in=new ObjectInputStream(fis);
        SoccerPlayer sp=(SoccerPlayer)in.readObject();
        return sp;
    }

L’exécution de mon code sur Mac donne

/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/java -Dfile.encoding=MacRoman -classpath /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/deploy.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/dt.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/javaws.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/jce.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/plugin.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/sa-jdi.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/../Classes/charsets.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/../Classes/classes.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/../Classes/dt.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/../Classes/jce.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/../Classes/jconsole.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/../Classes/jsse.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/../Classes/laf.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/../Classes/ui.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/apple_provider.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/dnsns.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/localedata.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/sunjce_provider.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/sunpkcs11.jar:/Users/nicolasmartignole/IdeaProjects/Test2/out/production/Test2 FileSystemStorageEngine

Soccer player name: Nicolas Martignole

Process finished with exit code 0

Lorsque la class n’est pas sérialisable

Nous allons parler de l’exception java.io.NotSerializable. Mais avant tout, je dois continuer à rappeler quelques mécanismes de Java.

Reprenons notre class SoccerPlayer et modifions-là afin qu’elle ne soit pas sérialisable. Je vais créer un objet « PlayerPosition » qui représente sur le terrain le poste du joueur. Cet objet ne sera pas sérialisable car il est dynamique. Un joueur défenseur peut jouer aillier (enfin je crois) et donc nous imaginons qu’il n’est pas possible de sérialiser cette information.
Peu importe le code de la class SoccerPosition, nous avons simplement besoin d’avoir une instance de celle-ci dans la class SoccerPlayer. La class SoccerPosition n’implémente pas l’interface java.io.Serializable.

La class PlayerPosition est très simple:

public class PlayerPosition {
    String positionName;

    public PlayerPosition(String s) {
        positionName =s;
    }

    public String getPositionName() {
        return positionName;
    }

    public void setPositionName(String positionName) {
        this.positionName = positionName;
    }
}

Nous ajoutons une instance dans SoccerPlayer:

public class SoccerPlayer implements Serializable {
    private String name;
    private Date birthDate;
    private int number;

    private PlayerPosition position;

    public SoccerPlayer(String name, Date birthDate, int number, PlayerPosition p) {
        this.name = name;
        this.birthDate = birthDate;
        this.number = number;
	this.position=p;
    }

Je modifie le constructeur de SoccerPlayer afin de passer une instance de PlayerPosition. Voyons maintenant lorsque l’on relance le programme pour sérialiser ce qui se passe:

public class FileSystemStorageEngine {
     private static DateFormat df = DateFormat.getDateInstance(DateFormat.SHORT, Locale.FRANCE);

    /**
     * Creates a new player, performs a serialiation test.
     * @param args is cl args.
     * @throws Exception for any Exception, I don't want to deal with it in my sample.
     */
    public static void main(String[] args) throws Exception{
        SoccerPlayer player = new SoccerPlayer("Nicolas Martignole",
					df.parse("24/09/1975"),
					10,
					new PlayerPosition("Goal")
					);
        performSerialization(player);

        SoccerPlayer loaded=reloadSoccerPlayer();
        System.out.println("Soccer player name: "+loaded.getName());

    }

    private static void performSerialization(SoccerPlayer player) throws ParseException, IOException {
        FileOutputStream fos=new FileOutputStream(new File("test.ser")) ;
        ObjectOutputStream out=new ObjectOutputStream(fos);
        out.writeObject(player);
    }

    private static SoccerPlayer reloadSoccerPlayer() throws IOException, ClassNotFoundException {
        FileInputStream fis=new FileInputStream(new File("test.ser")) ;
        ObjectInputStream in=new ObjectInputStream(fis);
        SoccerPlayer sp=(SoccerPlayer)in.readObject();
        return sp;
    }
}

Avant tout, notez que si vous n’instanciez pas de PlayerPosition pour la class SoccerPlayer, tout va bien se passer. C’est pour cette raison que j’ai mis à jour le constructeur de SoccerPlayer pour forcer l’affectation d’une PlayerPosition.

Après avoir compilé, le programme plante:

Exception in thread "main" java.io.NotSerializableException: PlayerPosition
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081)
	at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
	at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
	at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
	at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
	at FileSystemStorageEngine.performSerialization(FileSystemStorageEngine.java:34)
	at FileSystemStorageEngine.main(FileSystemStorageEngine.java:24)

Ici Java identifie facilement que la class PlayerPosition ne peut pas être sérialisée. Là où souvent vous aller avoir des soucis, c’est avec un serveur d’application comme JBoss ou Weblogic. Le mécanisme de passivation permet à un serveur d’application de libérer de la mémoire en stockant sur le disque des objets sérialisés. Lorsque la passivation échoue, les objets de la session EJB de l’utilisateur ne pourront pas être restaurés. D’où cette exception.

Avec un serveur J2EE et des EJB 2.1, comment retrouver quelle classe n’est pas sérialisable ?

Voici l’astuce du jour (et l’objet de ce billet):

1. Lancer le serveur d’application en mode debug sur une socket
2. Se connecter via Eclipse ou IntelliJ sur le serveur J2EE en démarrant une session de remote debug avec Java 5.
3. Charger les écrans dans l’application Web en se connectant
4. Configurer Eclipse ou IDEA IntelliJ pour que le debugeur s’active lorsque l’exception java.io.NotSerializable est levée (voir plus bas)
5. Attendre que l’EJB se passive
6. Votre IDE doit alors se réveiller et vous êtes arretés à l’endroit où la Thread du serveur d’application est entrain de faire la sérialisation. Avec l’inspecteur d’objet d’IntelliJ il est facile d’identifier quelle classe n’est pas serializable

Sur JBoss la passivation d’un Session Statefull Bean est reglé à 10 minutes, je ne vais pas attendre aussi longtemps

En effet, il est facile de configurer JBoss afin de passiver tout de suite des Beans. Je vais donner l’explication pour JBoss 4.2.2.

Ouvrez le fichier $JBOSS_HOME/server/default/conf/standardjboss.xml avec votre éditeur de texte favori (vi). Dans ce fichier de configuration, la section //container-configuration// définit la configuration du containeur. Chaque configuration spécifie des éléments tels que l’invoquer à utiliser, la politique d’interception de jboss, le nombre d’instances de caches et les files d’attente de thread, la configuration du persistence manager et enfin la partie sécurité.
Nous allons regarder plus en détail la section « container-cache-conf ». Cet élément est passé à l’implémentation de l’InstanceCache si celle-ci supporte l’interface XmlLoadable. Vous pouvez donc implémenter votre propre mécanisme de cache si vous le désirez. Les implémentations actuelles de Joss InstanceCache dérivent de la classe abstraite « org.jboss.ejb.plugins.AbstractInstanceCache ». Cette classe implémente l’interface XmlLoadable et donc sera capable de charger notre configuration.

Examinons le fichier standardjboss.xml

      org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy
      
          50
          1000000
          300
          600
          400
          60
          1
          0.75
      

Deux implémentations possible de CachePolicy sont utilisées dans le fichier standardjboss.xml avec le support d’une configuration que nous allons voir dans un instant
Les deux implementations sont

• org.jboss.ejb.plugins.LRUEnterpriseContextCachePolicy
• org.jboss.ejb.plugins.LRUStatefulContextCachePolicy

Dans JBoss 4.2, les Entity beans utilisent LRUEnterpriseContextCachePolicy. Les stateful session bean utilisent LRUStatefulContextCachePolicy.
Voici ce qu’il est possible de configurer:

• min-capacity nombre d’éléments minimum du cache
• max-capacity nombre maximum d’éléments du cache
• overager-period : durée en secondes entre 2 exécutions du système de nettoyage du cache. Lorsque ce système s’active, les beans dont l’âge est supérieur à max-bean-age sont retirés du cache pour être passivé. Vous voyez donc où nous allons en venir.
• max-bean-age : donne le temps maximum en seconde Durant lequel un bean peut être inactive avant d’être passive.
• resizer-period: durée en secondes entre 2 exécutions de la thread du “resizer”. Cette tâche se charge de redimensionner le cache en se basant sur les 3 proprietés suivantes. Lorsque cette tâche s’exécute, elle vérifie le temps écoulé entre 2 caches miss et si cette période est inférieure à « min-cache-miss-period » alors le cache est agrandit à la valeur « max-capacity » en utilisant le facteur « cache-load-factor ». Si la période par contre entre 2 miss caches est plus grande que la valeur de “max-cache-miss-period » alors la taille du cache est réduite en utilisant la valeur de « cache-load-factor ». Ce système permet d’avoir un cache de beans adapté à la charge du serveur avec JBoss.

En plus des paramètres précedents, LRUStatefulContextCachePolicy pour les Session Stateful Bean a les éléments suivants

• remover-period Spécifie une période en secondes à attendre entre l’exécution de la tâche de nettoyage du cache. La tâche « remover task » se charge de passiver les EJB qui n’ont pas eu d’accès depuis « max-bean-life » secondes. Ce système différent permet de vider les EJB qui ont été passivés afin d’éviter de remplir par exemple le disque. Ce n’est pas le mécanisme de la passivation. C’est un mécanisme de nettoyage des beans sérialisés sur le disque et qui n’ont pas été réactivé depuis « max-bean-life ».
• max-bean-life Spécifie la période maximale en seconde d’inactivité pour un bean avant que celui-ci ne soit détruit de l’espace de passivation.

Comment voir si un EJB peut être passivé et restauré facilement avec JBoss ?

Nous arrivons enfin à l’explication, après avoir parlé sérialisation et JBoss. Editez la section container-cache-conf pour le container « Standard Stateful SessionBean ».
Vous pouvez limiter le nombre de beans en cache, et donc forcer la passivation pour les beans les plus anciens :
Ici je déclare que les beans doivent être passivés après 30 secondes (max-bean-age), et qu’ils ont une durée de vie de 1800 secondes(max-bean-life). Cela me laisse du temps pour tester l’activation après passivation. Toutes les 25 secondes je vérifie mon cache afin de voir ce que je dois passiver (overage-period). Toutes les 120 secondes (remover-period) je regarde si je ne peux pas effacer du disque de vieux beans passivés. Je ne touche pas à ce qui est redimensionnement du cache (resizer-period).

        org.jboss.ejb.plugins.LRUStatefulContextCachePolicy
        
          10
          30
          25
          30
          400
          60
          1
          0.75
          120
          1800
        
      

Comment désactiver la passivation des EJB avec JBoss ?

C’est possible, quoique par forcément souhaitable. JBoss fournit une implémentation de CachePolicy appelée org.jboss.ejb.plugins.NoPassivationCachePolicy.
Cette police ne passivera jamais une instance. Elle est basée sur une Map en mémoire qui ne retire jamais les beans sauf si ceux-ci sont explicitement retirés

Pour désactiver la passivation :

    
      Standard Stateful SessionBean
        
          org.jboss.ejb.plugins.LRUStatefulContextCachePolicy

J’espère que ce petit guide vous sera utile, n’hésitez pas à me contacter si vous chercher un expert JBoss pour faire du tuning ou si vous avez besoin de conseils pour votre application.

org.apache.jasper.JasperException: Unable to compile class for JSP:

An error occurred at line: 22 in the generated java file
The method getJspApplicationContext(ServletContext) is undefined for the type JspFactory

Stacktrace:
	org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:92)
	org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:330)
	org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:415)
	org.apache.jasper.compiler.Compiler.compile(Compiler.java:308)
	org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
	org.apache.jasper.compiler.Compiler.compile(Compiler.java:273)
	org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:566)
	org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:311)
	org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
	org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
	javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
	com.rfs.j2ee.KiWI.util.CompressFilter.doFilter(CompressFilter.java:86)
	com.rfs.wfsignon.web.SignOnFilter.doFilter(SignOnFilter.java:186)
	com.rfs.j2ee.KiWI.util.EncodingFilter.doFilter(EncodingFilter.java:38)
	org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)

Cette erreur est toute bête: l’implémentation de la class JspFactory retournée par le classloader charge une version qui se trouve dans votre EAR ou dans votre WAR. Pour nous en effet nous avions servlet-2.3.jar à la racine de l’EAR (construit avec maven2). Bref il suffit de retirer cette archive de l’EAR et l’application fonctionnera à nouveau. Pensez aussi à retirer un éventuel j2ee.jar qui n’a rien à faire à la racine de votre EAR.

Pour exclure servlet-2.3.jar et jsp-api.jar avec Maven2 lors du packaging, ajouter dans le pom.xml qui genere l’EAR une dependency en forcant le scope à la valeur « provided« :

    <dependencies>
        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>servlet-api</artifactId>
            <version>2.3</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>jsp-api</artifactId>
            <version>2.0</version>
            <scope>provided</scope>
        </dependency>

    </dependencies>

J’en profite pour vous donner l’adresse d’un article de présentation et de mise en route de Maven2 très bien écrit: sur le Blog de Jean-François Helie

English version: The JspFactory that is loaded by the Jasper is not the correct one. Check that you don’t have a JspFactory impl in your EAR or WAR/WEB-INF/lib subfolder. In Tomcat 6, the JSP API classes are found in jsp-api.jar and servlet API classes are found in servlet-api.jar, with both located in the lib directory of the Tomcat 6 installation. Any servlet.jar you find
involved with this server would contain out of date classes for this
server. Delete servlet-2.3.jar from your EAR.

Voici quelques questions/réponses sur ce que l’on peut faire aujourd’hui avec JBoss Seam pour compléter l’article de Michael Yuan. J’espère vous apporter ici des nouvelles fraiches par rapport à ce que l’on trouve sur le net.

Est-ce que JBoss Seam est payant?

Non, JBoss Seam est distribué sous licence LGPL.

Est-ce que je dois absolument utiliser le serveur d’application JBoss pour profiter de Seam?

Non, JBoss Seam peut être aussi déployé dans un containeur léger de type Tomcat. Des portages sont en cours pour IBM Websphere, des utilisateurs ont aussi déployés Seam sur le serveur SUN Glassfish. Bref les développeurs de JBoss Seam ont clairement envie de fonctionner sur le plus de serveur d’applications du marché possible. Voir aussi ce post pour Glassfish

Est-ce que JBoss Seam sait génerer des applications Web 2.0 avec Ajax ?

La réponse est oui. A la base, Seam utilise JSF (Java Server Faces) et la communauté open-source propose des API qui sont maintenant intégrées de facto dans JBoss Seam. Il devient ainsi très simple d’ajouter des formulaires qui se mettent à jour partiellement via Ajax par exemple. D’autre part le module Seam Remoting permet au développeur d’implémenter une vraie application Web 2.0 facilement

Est-ce que Seam peut envoyer des emails ? faire des traitements la nuit ?

JBoss Seam peut en effet envoyer des emails. Il est possible de génerer un fichier PDF par exemple et de l’envoyer chaque nuit. Pour l’envoi de l’email, l’api est simple et facile à utiliser. Le traitement de batch avec Seam se repose sur un moteur Asynchrone. Seam peut par exemple faire une tâche chaque heure, chaque nuit et déclencher un traitement. Tout ceci soit via l’api EJB3 d’asynchronisme, soit via l’api Quartz qui est plus puissante. En effet celle-ci permet de créer des tâches avec une date d’écheance par exemple.

Concernant l’envoi d’email, jBPM 3.2 qui est en cours d’intégration dans JBoss Seam 2.0 Beta 1 permet aussi d’envoyer un email lorsqu’une tâche est terminée.

Est-ce qu’il est possible de changer de langue, de locale à la volée ?

Oui en effet le support de l’internationalisation (i18n) est fortement intégré dans Seam, en partie via JSF. Par ailleurs il est possible d’ajouter un composant en 2 clics pour permettre de changer de langue et de Locale à la volée. Ce choix peut être persisté via un cookie. Il existe aussi une possibilité de changer le thème (la skin) d’une application (je pense au module Stylizer chez Reuters…) afin de changer l’aspect d’un site avec un seul clic.

Est-ce qu’Eclipse peut me permettre d’écrire des pages graphiquements ? Existe-t-il un studio ?

J’ai lu que Macromedia prépare une version de DreamWeaver qui reconnait parfaitement JSf 1.2. Cela devrait permettre de coder les pages de la vue plus rapidement. Attention cependant, avec richFaces, ajax4jsf et iceFaces de toutes les façons ces studios ne fonctionnent pas. Il vaut mieux travailler en mode « explode ». Ce mode consiste à compiler votre application, à déployer sur JBoss une arborescence explosée (EAR dans lequel on retrouve un repertoire WAR…). Cela permet alors de travailler sur les fichiers .xhtml (avec Facelets) sans devoir reconstruire tout l’EAR à chaque fois. Vous n’avez alors qu’à lancer un « ant restart » de temps en temps si vous touchez à la partie Java. C’est très pratique.

Par ailleurs sinon je vous conseille de dépenser un peu d’argent pour acheter IDEA IntelliJ. C’est mon quart d’heure sponsor ce soir. Mais entre Eclipse+MyEclipse vs IntelliJ, il n’y a pas photos. IntelliJ reconnait le format xhtml, les JSF et surtout les annotations de JBoss Seam ce qui au passage devrait convertir j’espere quelques lecteurs ici. Ajoutez-y le support de JBoss AS en natif pour controler, débuger JBoss (comme JBoss IDE mais en mieux) et voilà, vous allez craquer.

Si vous avez d’autres questions, n’hésitez pas à commenter.

Tout d’abord au niveau des packages, comme Gavin l’a expliqué dans un post (voir forum JBoss), il y a eu une réorganisation et un nettoyage des packages. De manière très concrete, il faut prévoir un peu de refactoring au niveau des imports mais rien de très compliqué.

Au niveau de la configuration, attention au fichier /resources/WEB-INF/components.xml qui a pas mal changé. L’intégration du système d’Identity de jBPM fait qu’il faut reprendre ce fichier, sous peine sinon de se retrouver avec ce genre d’exception:

11:20:48,973 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/seam-matstan]] Exception sending context initialized event to listener instance of class org.jboss.seam.servlet.SeamListener

java.lang.RuntimeException: error while reading /WEB-INF/components.xml
        at org.jboss.seam.init.Initialization.initComponentsFromXmlDocument(Initialization.java:136)
        at org.jboss.seam.init.Initialization.create(Initialization.java:86)
        at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:34)
        at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3854)
        at org.apache.catalina.core.StandardContext.start(StandardContext.java:4359)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:761)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:741)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:553)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Attention aussi au niveau de la qualification de nommage des composants dans Seam. Exemple trivial: j’ai une class Session qui traine dans ma conversation. Or il faut savoir que certains composants Seam sont branchés avec une @Factory… Si vous avez un attribut « session » que vous voulez injecter comme sur cet exemple:

   @In
   MyObject session;

… cela ne marche pas car Seam enregistre aussi ce meme nom pour la session Seam, en l’occurence ici org.jboss.seam.web.session.
En général il est bien de forcer les noms des composants pour éviter ce genre de problèmes.

Sinon je suis à fond dans jBPM. La version 3.2.1 que Gavin intégre (il y a des commits sur CVS en ce moment) offrira quelques nouvelles fonctions:

• Notification par email lors de l’execution d’une tâche en spécifiant notify= »true » dans une task-node
  
• Gestion de modèles d’emails pour cette partie
• Gestion des Calendriers. Cela permet par exemple de programmer une task durant les jours ouvrés d’une societé. Ou pour la finance, d’utiliser des calendriers cambistes afin d’affecter des tasks selon les dates d’ouverture de la bourse… (grand sourire)
• Gestion des « due Date », « start Date », « end Date » sur les tasks. Il devient facile aussi de demander au systeme d’envoyer un email de rappel 2 jours avant l’échéance d’une task par exemple. Tout ceci grâce à jBPM.

Concernant la partie JSF, je déconseille d’essayer d’installer Tomahawk. Dommage car l’un des composants d’agenda est sympa. Mais Gavin King sur les forums de JBoss a expliqué les problèmes rencontrés pour faire fonctionner cette API avec Seam 2.0

Coté Ajax4jsf et RichFaces, ces deux API sont très simples à utiliser et vraiment mature. Pour se faire une idée des applications Seam 2.0, il faut vraiment tester seamdiscs. Sur le modèle de MySpace, la démo montre quelques composants de RichFaces.
Je vous laisse tester par exemple la SuggestionBox en allant sur le site d’Exadel:
http://livedemo.exadel.com/richfaces-demo/richfaces/suggestionBox.jsf?c=suggestionBox

Merci aussi sinon pour les emails reçus, j’ai de plus en plus de monde qui vient sur ce blog, avec aujourd’hui plus de 400 visiteurs uniques différents. Cela commence à faire du monde, je vois que les gens viennent de partout, cela fait vraiment plaisir de lire vos commentaires et vos encouragements. Merci !

Par rapport à d’autres librairies comme tomahawk qui a du mal à s’intégrer avec Seam, ICEFaces a été testé et validé avec JBoss Seam. Pour ma part je cherche un composant jsf d’agenda qui tienne la route. J’aimerai bien tester MyFaces Schedule mais pour mettre en place tomahawk dans JBoss il faut désactiver l’implémentation jsf par défaut. Je n’ai pas encore testé, car je regarde une autre alternative utilisant Google Agenda. L’idée est de récuperer l’agenda via du HTML, ce que j’ai réussi à faire hier soir sans trop d’effort. Google met aussi à disposition une API Java pour poster des évenements vers un agenda Google. Bref j’ai tout, sauf qu’au niveau de l’ergonomie l’agenda qui s’affiche en mode HTML est moins sympa à utiliser que la vraie version de Google Agenda… Donc me voilà revenu au point de départ.

Sinon JBoss Seam est vraiment puissant… mais chut, tant pis pour ceux qui se réveilleront trop tard…

Invalid byte 2 of 3-byte UTF-8 sequence.

Pour éviter cela il suffit de configurer le connecteur Tomcat embarqué dans JBoss en éditant le fichier jboss-4.2.0.GA\server\default\deploy\jboss-web.deployer\server.xml.
Ouvrir server.xml fichier et ajouter un tag useBodyEncodingForURI et un tag URIEncoding comme sur cet exemple:

    <Connector port="8080" address="${jboss.bind.address}"
         maxThreads="250" maxHttpHeaderSize="8192"
         emptySessionPath="true" protocol="HTTP/1.1"
         enableLookups="false" redirectPort="8443" acceptCount="100"
         useBodyEncodingForURI="false" URIEncoding="UTF-8" 
         maxKeepAliveRequests="50"/>

Relancer le serveur et tester en éditant une page avec des caractres iso (accents, le signe EURO par exemple)

Voir la doc de tomcat pour plus de details

Update dimanche soir je précise que pour être complétement tranquille le mieux est de sauver vos fichiers xhtml en UTF-8 et de spécifier l’encoding dans l’entête de la page :

    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>