Anthony Patricio’s Blog

Decrypting another JPA benchmark

Posted in Persistance / Données by apatricio on octobre 23, 2012
Reviewing a benchmark is always an interesting task. Unfortunately it is often useless because benchmarks are rarely a good representation of real life conditions.
Last month, someone told me a new JPA implementation was trying to make noise. The author was making some buzz almost everywhere on social networks, commenting on popular articles and writing 2 articles claiming that this implementation was over 15 times faster than Hibernate. And here we are again. This sort of buzz happens every 2 years, it’s a cycle, there is nothing we can do about that.

The benchmark

Reading more about the implementation, the focus is made on fine grained tuning on every single line of code which is a really brave approach. However the way to announce « The New JPA Implementation That Runs Over 15 Times Faster… » is not a good way to promote the implementation. Anyway let’s have a closer look at the benchmark that allowed the author to conclude « 15 times faster ».
The benchmark is essentially composed of massive inserts, updates, deletes, queries by packet of 250 iterations. The domain model is composed of
  • 4 entities, yes 4 entities,
  • no inheritance, it sounds weird that a fabulous JPA implementation is not including more mapping configurations in its benchmark
  • eager fetching enabled (no subselect fetching for example),
  • cascading enabled,
  • no versioning

Last but not least, the benchmark targets an in-memory database, yes this is where it becomes suspicious.

15 times faster… faster what?

The big problem behind the title is that faster is not at all related to response time. The author tries to explain it, it’s related to CPU load, fair enough but could he clearly explain the consequences on a full system?
The fact is that the results are really hard to read and there is no relative view of the benchmark. You are told that Batoo might take 15 times less CPU time than Hibernate and what? The danger here is to mix internal APIs CPU load with the full persistence cycle composed of JPA internals, JDBC driver, networking, database engine. We all know, at least I hope so, that most of the time is spent on network and database so is this really important to focus _that much_ on JPA internals? Is hibernate that slow? Will Batoo solve your performance issues?
Let’s be extremely clear here, most of the performance issues users are facing are NOT because of JPA internals CPU load, the problems are almost always related to a slow database, too fat entity managers, inefficient queries. There are 3 general ways to solve these issues:
  • check your database !!! JPA is NOT going to fix a database internal problem
  • make a better use of the database and JPA
  • tune your own code, that requires various features and that is going to have a really big impact on the global performance numbers. In order to do so, the frameworks you are using must offer various features, this is exactly what Hibernate does: allows you to tune every single interaction your are triggering with the database.

Impacts: the Global view

I’m not going to rely on the timers provided by the benchmark. People are interested in checking how a system globally reacts when switching from one software option to another. I asked my friend and mate what tool a sysadmin would use to have a good view of the resources consumed by a process. « Easy » he told me, use the time command.
The time command runs the specified program command with the given arguments. When command finishes, time writes a message to standard output giving timing statistics about this program run. These statistics consist of (i) the elapsed real time between invocation and termination, (ii) the user CPU time (the sum of the tms_utime and tms_cutime values in a struct tms as returned by times(2)), and (iii) the system CPU time (the sum of the tms_stime and tms_cstime values in a struct tmsas returned by times(2)).
So I’m going to use time mvn test with the good format to grab the CPU numbers.
Some would say it’s not accurate. I would answer that it allows to measure a real relative impact on a global system not at the thread level.
We’ll see how much CPU% are consumed by the benchmark.
The good thing with mvn test is that we’ll also get the total time execution.

Well used Hibernate is ways faster than noob Hibernate 

In order to do some tuning, I’ll start with a low BENCHMARK_LENGTH iteration number, let’s say 5. That is 5 times each sub test, one subtest globally doing 250 iterations.
Since the in-memory db will be started by the root process, time command will also catch the DB load which we don’t want but we are just tuning the hibernate config for the moment.

Shoot 1: In memory derby, BENCHMARK_LENGTH 5

Hibernate 13 seconds 200% CPU
Batoo 9 seconds 210% CPU
Hibernate based setup _globally_ consumes less CPU but is also slower. Wait, I’ve said that this measure was including the database engine load. Having in mind that Batoo is claiming it consumes 15 times less CPU than hibernate what would that mean? That would mean that the JPA internal  CPU load is extremely low compared to the in-memory database CPU load … and still, we have an unsolvable equation here, we need more tests. Anyway, I already think know that CPU time consumed by JPA may not be a critical issue at all. But wait, small benchmark size and in memory database? This is irrelevant.
Let’s move to a local MySql instance, in-memory databases might be good for development, not for production. If I want a memory based config, I’ll got for Hibernate + Infinispan + a real database instance, not in-memory.

Shoot 2: Local MySql, BENCHMARK_LENGTH 10

Hibernate 44 seconds 64% CPU
Batoo 36 seconds 55% CPU
Batoo is the winner. Should we stop here? Certainly not.
Something is wrong. The good thing with hibernate, a _mature_ JPA implementation, is that it allows tons of tuning, being in the mapping, in the queries well everywhere. 
I remember 7 years ago, one guy at work was insulting Hibernate saying it was a piece a crap because he was observing memory issues and/or extremely long response times. One quick look at the hibernate documentation, 2 mapping parameter updates, more care of the entity manager (well Hibernate Session at that time), allowed to solve the memory issue and allowed a 10 000 faster execution. I promise it’s true, 10 000 times faster in response time.
A quick look at the documentation informs us that we should use the following global config parameters:
<property name="hibernate.jdbc.batch_size" value="50"/>
<property name="hibernate.order_update" value="true"/>
<property name="" value="true"/>
More important: checking the INFO level logs, you’ll notice that the author of the benchmark left the auto commit mode. For someone who claims to be implementing the fastest JPA implementation ever, he should review the basics.
So let’s add
<property name="hibernate.connection.autocommit" value="false" />
and rerun the test with something bigger, I also raise the BENCHMARK_LENGTH to 100. 

Shoot 3: Local MySql, BENCHMARK_LENGTH 100

Hibernate 5 min 1 seconds 29% CPU
Batoo 4 min 52 seconds 22% CPU
29% versus 22% CPU… We are talking about a production server. In my case I used a 8 core CPUs 3 years old server. 
29% of one CPU … 
This benchmark is using 
  • 3.625% of my global System CPU capacity with hibernate
  • 2.75% of my global System CPU capacity with Batoo
It seems we are really far from the 15 times faster!

A more realistic environment

I won’t stop here, the author says that his motivation is to reduce cluster size thanks to his optimized implementation. So let’s say I don’t have 8 core, only 2. Here I might be interested in reducing my CPU load.

Who says cluster, also says remote database. And even without a cluster, production system will host the database in a different server.
So I set up a really fast LAN, excellent ping and bandwidth.
Here are the new results

Shoot 4: Remote MySql, BENCHMARK_LENGTH 100

Hibernate 16 min 30 seconds 6% CPU
Batoo 17 min 55 seconds 5% CPU
(Is it me or Hibernate is faster ?)
Which, for a 4 core CPUs system means
  • 1.5% of my global System CPU capacity with hibernate
  • 1.25% of my global System CPU capacity with Batoo
or for a 8 core CPUs system means
  • 0.75% of my global System CPU capacity with hibernate
  • 0.62% of my global System CPU capacity with Batoo
Yes Batoo is better in terms of CPU load but with such low levels, who cares? The persistence engine is always waiting for the database!
In the middleware side we have a very low CPU load (at least for the JPA part), what about the DB server side? We have one CPU over the 4 constantly above 80%. A second one above 40%.

Putting all of this together, Batoo MAY consume slightly less CPUthan Hibernate but the actual database load on these benchmarks far outweighs the load imposed by either Batoo or Hibernate.

And, since the internal ORM performance is a relatively minor issue, we should think about the products’ features.
Why is that important?
  • write stupid queries and you’ll get network, database and possibly memory issues (no matter if you use Hibernate or Batoo) -> query oriented advanced features are welcome
  • be idiot using the entity manager and you’ll observe slowness and memory issues (no matter if you use Hibernate or Batoo) -> get some training and certification, persistence is not something easy, you need SKILLS 
  • not talking about the DB slowness … if you do not understand RDBMS, you MUST work with a DBA, this is not an advice, this is a requirement.
  • if you are an expert in JPA, and your application is slow because of the database, you may have hit the RDBMS limitations. Give a try to Hibernate OGM with a NoSql supported database.

Shoot 5: Remote MySql, BENCHMARK_LENGTH 100, 2 concurrent run

I’m not going to provide the results but response times are impacted by 50%. CPU load is close to 2%

Conclusion: I don’t care these CPU optimizations I prefer FEATURES!

I honestly cannot imagine JPA being a cause of CPU problem in a real life scenarios. I’m also not forgetting that Hibernate is a 12 years old project. Talented people are working full time on it, the major version is 4, that means it has been heavily totally reworked 4 times. So that’s enough to understand that it is well written and that efforts are put in the most critical area: offering features.

I did online community support then official Red Hat support. I’ve seen query response times issues (1), memory issues (2) sometimes but I can’t remember about a CPU issue related to JPA internals.

To solve 1 and 2, you need skills but also features that help you tune your code. Like being able to use a specific database syntax (dialects), or  tune associations loading, I could continue on 300 pages here and I would recommend you simply consult the Hibernate documentation’s index.

Tagged with: , , ,

La gestion des compétences

Posted in Actu / Anecdote by apatricio on octobre 3, 2012

J’ai lu avec intérêt le billet suivant:

Je suis sur le fond entièrement d’accord avec l’auteur mais la forme pose problème, ce qui est aussi relayé par certains commentaires. La question de la responsabilité de la formation est forcément soulevée.

Le développeur est-il seul responsable de sa formation? Dans la plupart des corps de métier, la réponse est évidemment non. Sous prétexte qu’il y a tonnes de tutoriels sur le web et/ou que le développeur doit forcément être un passionné, il devrait passer son temps libre à s’auto-former… Soulignons au passage que si tout travailleur doit savoir *apprendre*, tout le monde n’est pas censé être pédagogue et l’auto formation ne sera jamais aussi efficace qu’un échange avec un instructeur qui a la pédagogie innée.

Le cas du débutant

Le développeur (souvent ingénieur, ce n’est pas rien) sort de l’école avec une base plus ou moins bonne, théorique, rarement pragmatique. Souvent en stage de dernière année pré embauche il sera directement vendu comme ingénieur au client (et non comme stagiaire). Certes, c’est plutôt formateur comme première approche s’il est au contact de coachs qui ont le temps de le former. Ce n’est pas souvent le cas, après une introduction d’une demi journée il sera en face de son IDE et devra pondre des lignes. La qualité du code produit laissera forcément à désirer. Peu importe, le client délègue souvent la technique et ne sera donc pas en mesure de capter la pauvre qualité produite. Le développeur débutant n’est clairement pas responsable de cette situation. L’effet papillon d’une telle production est qu’un second développeur non formé intervenant sur ce code bancal par la suite se dira « tiens c’est comme ça qu’on fait ici? » puis le copier/coller fera son oeuvre. De temps à autre un presta tiers spécialisé dans la revue de code (le bon rôle) pointera du doigt le problème et les développeurs s’en prendront forcément plein la figure par le client et par leur chef de projet.

En passant qu’elle est la différence entre un développeur et une personne qui fait de la revue de code? L’un peut ne disposer que de très peu de jours pour implémenter un cas d’utilisation complexe alors que l’autre, pour le coup reconnu pour ses compétences techniques, dispose en proportion de plus de temps pour revoir le code produit et l’incriminer. Au final, il se pourrait très bien que les 2 disposent des mêmes compétences, ils n’ont simplement pas les mêmes moyens.

Coder c’est facile!

Bizarrement, lorsque l’on parle d’informatique d’entreprise, on a le sentiment que la compétence peut facilement être acquise. Hors les outils, frameworks, standards, buzz se multiplient à une vitesse trop élevée pour que les choix de production finaux suivent. Le développeur doit alors constamment jongler entre les oldies (struts, frameworks faits maison,…), les standards de fait et bonnes spécifications (Spring, JPA, JSF 1), les nouvelles specs (JPA 2, JSF 2, CDI)  mais aussi les *nouveautés* (ce terme étant plus ou moins faussé et très relatif) (NoSQL, Scala, …). Les managers, clients et autres RESPONSABLES n’imaginent pas combien il est éprouvant de passer d’une techno à l’autre, c’est intellectuellement épuisant. Car utiliser une techno ne se limite pas à en maîtriser la syntaxe ou même les fichiers de configuration , c’est surtout en comprendre la philosophie et pourquoi/quand l’utiliser et en connaître ses bonnes pratiques et limites.

Administrer des systèmes et gérer des projets c’est difficile sensible

Il est encore plus étrange à mon sens, que les budgets formations et certifications soient si pauvres voire nuls en comparaison aux mêmes budgets de formations et certifications des administrateurs dans leur ensemble. J’ai accès à certains chiffres éloquents, un administrateur OS, DB, réseau et Serveur d’application se verra proposer régulièrement des formations pour mise à jour de ses compétences. Celles-ci se verront validées, mais surtout mises en valeur par l’obtention d’une certification. Pourquoi ce grand écart entre les admins système et les développeurs? La réponse super naïve est de dire que les admins flirtent avec le réseau, l’hardware dans son ensemble mais aussi et surtout la sécurité. En effet, un mauvais admin pourrait laisser ouvertes des failles de sécurité , il plantera une config routeur qui bridera à 10% la capacité réseau ou plantera le DNS, quand à l’admin serveur d’application il pourra planter son clustering en le paramétrant en UDP là où de toute évidence, seule la config TCP est autorisée…

Les managers pensant comme celà sont peut être naïfs ou ils se voilent la face. Ils n’ont pas conscience que tous ces éléments critiques (sécurité, engorgement hardware, scalabilité) peuvent être mis en péril au niveau de l’application elle-même. La plus petite des webapps peut provoquer des désastres. Un mauvais développeur mal formé pourra en 3 classes pourrir votre SI, ouvrir un faille de sécurité béante vers votre BDD (SQL injection) et monopoliser votre réseau inutilement (requêtes faites à la va vite sans réellement comprendre ce qu’il se passe derrière). Vous pensez ces symptômes d’un autre âge? Avez-vous entendu de la dernière grosse faille Yahoo? C’était cette année: , cause: SQL injection, chose que l’on peut créer dans n’importe quelle application en utilisant mal JPA, JDBC, iBatis. Etre admin système requiert à mon sens des compétences solides, certaines pas évidentes mais pas vraiment d’un niveau de complexité plus élevé que le développeur.

Passons maintenant aux chefs de projet. Pourquoi m’en prendre à eux? Parce que justement je ne m’en prends à personne, simplement dans beaucoup de domaines, les qualités d’un chef de projet sont reconnues en opposition à celles du développeur que l’on trouve banales, normales, aisées à acquérir. Alors certes, un chef de projet doit impérativement avoir un bon relationnel, être un bon communiquant et posséder un sens de l’organisation et de gestion des *ressources* et compétences _sick!_ de son équipe la plus pertinente possible. En option premium il possédera des bases sur le métier du client et des bases techniques de surface. Une fois écarté le stéréotype du développeur geek qui ne sait aligner 2 mots et qui vit en ermite devant son dual screen, le développeur ne possède t’il pas aussi les qualités que l’on loue au chef de projet? Ou tout du moins une partie commune? Chacun sera libre de répondre.

Après 2 ans en TMA sur une appli delphi, swing ou struts, le pauvre développeur n’a aucune motivation/raison pour aller de lui même se mettre techniquement à jour, pourtant on a tendance à estimer que c’est implicite dans nos domaines. Comment l’empêcher de vouloir se reconvertir/évoluer vers un poste de chef de projet? Un poste qui n’est pas simple certes mais qui au moins ne sous-entends pas de constamment revoir ses compétences techniques et surtout un poste reconnu.

Tout le monde y trouve son compte … sauf le développeur

Les formations ça coûte de l’argent. Dans un domaine hyper concurrentiel, une SSII qui formerait officiellement ses équipes devrait répercuter ces coûts sur les clients. Elle serait moins compétitive. Ainsi on ne peut rendre les directeurs de marché responsables de ce système.

Si j’étais pour la théorie du complot et je ne le suis pas, j’avancerai l’argument suivant:

  • un développeur correctement formé voire certifié produit plus vite mais surtout mieux
  • il en résulte des coûts de maintenance corrective moins élevés
  • mais aussi et surtout des coûts de maintenance évolutive réduits
  • donc globalement moins de business à moyen terme

La vérité est probablement ailleurs. L’ingénierie du logiciel bouge trop et trop vite. On assiste à des évolutions majeures, à l’émergence de nouveaux modèles tous les 2 à 3 ans. Dans ces conditions est-il réaliste d’envoyer son armée d’ingénieurs en développement en formation aussi souvent? Une solution est la spécialisation des effectifs mais là encore, on demande très souvent au développeur de s’adapter à tout et très vite.

Le client qui *pense* qu’écrire une application coûte ce qu’elle coûte avec les TJM (ou forfaits, les proportions restent respectées) constatés de nos jours devraient se poser la question suivante: « et si je demandais à chaque profil qui est amené à travailler sur mes applis qu’il possède dans ses bagages une vraie formation et/ou certification? ». Peut être devrait-il supporter une hausse des tarifs sur le court terme mais il se rendrait compte qu’au final il a tout à y gagner.

Je voterai donc pour une spécialisation plus prononcée des profils, qui serait validée et exigée par le client.

Nouveau livre en français sur JPA ?

Posted in Actu / Anecdote by apatricio on juillet 3, 2012

J’ai reçu plusieurs inputs cette semaine qui font que je me pose la question.

Le premier input est mon relevé de droits d’auteur. J’étais déjà surpris l’année dernière mais mon second livre continue de se vendre, à un rythme à peine inférieur aux 4 années précédentes. Étrangement, je ne suis pas super ravi car à mon sens, il est en partie déprécié. Sur le fond aucun soucis, les démonstrations sont toujours bonnes. C’est plutôt sur la mise en oeuvre de certains exemples que le livre laisse à désirer:

  • absence de maven
  • la partie EE est bien trop lourde, une mise à jour avec JBoss AS7 serait la bienvenue

Sur la forme, quelques ajouts seraient les bienvenus mais pas de révolutions énormes.

Un lecteur m’a récemment posé la question d’une nouvelle édition.

Je partirai peut être plutôt sur une série d’articles concrets et pédagogiques sur ce même blog avec possibilité de télécharger de vrais projets de développement.

Ahhhh si j’avais des journées de 35h ….


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.

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 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">
   <module name="javax.faces.api&quot; slot=&quot;main">
   <module name="com.sun.jsf-impl&quot; slot=&quot;main">
   <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"/>
  • 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 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: , , , ,

La certification, pourquoi faire ?

Posted in Actu / Anecdote by apatricio on juillet 29, 2011

Qui ne s’est jamais retrouvé dans une querelle d’experts sur une techno, sur le moyen d’implémenter un cas d’utilisation ou je ne sais quel aspect technique avancé. Lorsque l’on n’est pas initié soit même, et que l’on assiste à un tel débat, on est incapable de trancher, comme si l’on se trouvait au milieu d’une partie de poker face à deux gaillards prétendant tous deux avoir la main maximale, statistiquement proche de l’impossible, situation plutôt gênante lorsque l’on est client, chef de projet métier ou même employeur.

Pour toi développeur, technicien, archi avec la tête dans le guidon, ça peut être encore pire, tu peux te voir dé crédibilisé par un autre alors que tu es persuadé qu’il a tord, oui mais voilà, c’est un client, ou un concurrent qui est mieux vu. Le but ici n’est pas d’avoir raison mais bien de faire avancer le projet au mieux.

Que dire du directeur de marché, d’équipe ou responsable RH qui ne peut pas s’y connaître en technique (ce n’est pas son métier) qui va embaucher une personne selon le nombre de mots compliqués ou buzzables qu’il y aura sur son CV et qui, au premier projet livré, devra faire face à une montagne de bugs techniques plus bloquants les uns que les autres et à des réclamations en tout genre. La processus d’embauche mériterait un débat complet tellement il relève d’une problématique complexe: embaucher une personne compétente sur un domaine précis ça peut être très aléatoire. Pour tester un candidat il faut avoir soit même la compétence et/ou le test, le temps, bref ça coûte de l’argent tout ça et c’est une réelle stratégie de l’entreprise, un investissement, voire un risque si on embauche n’importe comment.

Il existe pourtant un moyen simple d’apporter des garantie de crédibilité: les certifications. Attention toutefois, il existe 2 types de certifications. La première s’apparente au code de la route, à savoir un QCM. A vrai dire, il n’y a que très peu d’intérêt à une telle formation, une bonne mémoire, la lecture d’un bouquin ou deux et hop, nous voilà certifiés. La seconde est plutôt semblable à l’examen de conduite, comment le candidat utilise t’il sa connaissance (et surtout son expérience) face à des cas réels ? Ces certifications là valent de l’or, aussi bien pour la personne certifiée que pour la personne qui va l’employer où faire appel à ses services. Pour l’employeur c’est la garantie de ne pas se tromper, pour le certifié c’est une garantie de pouvoir se faire respecter dans ses choix, ses développements, c’est un argument de taille, c’est aussi l’occasion de valoriser son CV et prétendre à un salaire plus élevé.

Chaque année des études sont faites pour lister les certifications les plus remarquables, généralement cela se traduit en % supplémentaire de salaire que l’on peut négocier si l’on a telle ou telle certification. Par exemple: Deux paramètres influent sur le résultat: la compétence testée bien sûr mais aussi indéniablement la qualité de l’examen. Etre certifié sur une technologie pointue, rare, très demandée mais via un examen QCM bateau est facile, ne sera pas reconnu et n’apportera rien à personne. Dans le tableau évoqué précédemment vous noterez la présence des certifications Red Hat sur l’OS entreprise RHEL. Depuis plusieurs années, les certifications Red Hat sont reconnues parmi les meilleures, souvent même au top 10 des certifications IT. Pourquoi?

Bien sûr car la compétences est recherchés mais aussi pour la qualité de l’examen lui même. Imaginez que l’on vous teste sur l’installation, le tuning, la réparation d’un système existant, sur des aspects utilisés par toutes les entreprises. Et bien c’est ce que propose Red Hat: que du cas réel, pas de piège. Tout son savoir faire sur la création de certification a été décliné sur les technologies JBoss. D’abord sur le serveur d’application, puis sur JPA, maintenant sur Seam 2, bientôt sur Portal, JPA 2, …

Conclusion, une certification s’est

  • pour le certifié,
    • valider ses compétences,
    • se faire reconnaître pour ses compétences,
    • valoriser son CV,
    • avoir plus de poids dans les débats et prise de décisions
  • pour l’employeur,
    • limiter les risques lors d’une embauche,
    • valider son investissement dans une formation pour un collaborateur,
    • une valeur ajoutée certaine chez le client dans le cadre de prestations, c’est décliner la garantie chez le client
En savoir plus sur les certifications Red Hat:
Si vous souhaitez formuler un souhait de certification, n’hésitez pas à me contacter.
Tagged with: , , , ,

JBoss Application Server 7, moins de 2 secondes au démarrage

Posted in Actu / Anecdote by apatricio on juillet 22, 2011

Après un long sommeil, je ne peux m’empêcher d’avoir envie de blogger sur JBoss Application Server 7.

Peut-être êtes-vous sur une autre planète et ne l’avez pas entendu mais cette dernière version du serveur d’application est tout simplement étonnante, bluffante, décoiffante. Habitué depuis des années à travailler sous JBoss AS, je connais sa robustesse, son sérieux mais j’en reconnais aussi sa lourdeur, taille au téléchargement, délai de démarrage, emprunte mémoire. Cette lourdeur m’avait même motivé à exploiter Arquillian, que je recommande toujours chaudement, lors de mes phases de développement.

Lorsqu’une équipe de costauds de la technique décide qu’il est temps, après des années, de revoir l’intégralité d’un serveur d’application, de plonger de trois niveaux dans les couches de bas niveau, d’appliquer des optimisations sur le moindre bloc, d’exploiter de nouvelles normes, techniques, frameworks, d’en créer lorsque l’existant ne donne pas 200% satisfaction et bien lorsqu’une dream team comme celle de l’engineering JBoss se met en marche, ça donne JBoss Application Server 7. Peut-être pensez-vous que j’en fais des montagnes, que je prêche pour ma paroisse, mais il faut le vivre de l’intérieur pour comprendre le travail que cela représente, la passion, que dis-je, la foie en une constellation de compétences au service d’un produit, qui plus est open source, c’est ce que je trouve génial, moi qui suis dans ce domaine depuis 8 ans (là je prends un coup de vieux). Alors, oh toi grand développeur au niveau de geekitude avancée, toi dont on ne distingue plus les doigts lorsque tu libères ton code, toi qui hot-déploies plus vite que ton ombre et qui redémarre ton serveur plus de 10 fois par heure, sache que JBoss a pensé à toi.

Stop au bavardages, voici quelques chiffres, je ne compare pas avec la concurrence, je ne suis pas là pour casser un concurrent juste pour montrer l’écart avec la génération d’AS précédentes. Jusqu’à ce jour j’utilisais EAP 5.1 (comprenez la version ‘product’ de JBoss AS 5). Je compare le profil standalone d’AS7 et le profil default d’AS5.

  • Emprunte mémoire: 350M contre 900M
  • Démarrage à vide: 1,8 secondes (je ne mens pas) contre 20 secondes
  • Démarrage avec la même application web basée sur Seam 2 et Hibernate 3: 7,8 secondes contre 28 secondes
  • Taille disque 126M contre 535M
  • Une console d’administration, pas trop tôt certains diront, oui ok je suis d’accord.

Certains me diront que la concurrence (tout du moins un AS concurrent très respectable au demeurant) sait faire depuis un petit moment déjà. A ces personnes je dis que l’intérêt ici est de pouvoir utiliser le même serveur d’app en dev et prod car il faut être réaliste, JBoss AS est très largement employé en production, comme en dev d’ailleurs. (attention je n’ai pas dit que le concurrent en question n’était pas utilisé en prod, ne me faites pas dire ce que je n’ai pas dit.)

Evidemment, tout ceci ne fait pas tout, il faudra juger et attendre pour prendre le recul et juger de la robustesse mais je ne m’en fais pas du tout pour ce point. Qui dit nouvelle génération, refonte totale, dit « j’arrive à rien déployer dans ce foutu AS de m…. ». Je confirme c’est ce que je me suis dit à ma première tentative de déploiement d’une appli que j’avais créée avec Seam 2 et Hibernate 3. Pour info AS7 fournit Hibernate 4. Un article prochain expliquera comment déployer une telle appli et cerise sur le gâteau l’article devrait être très court car il n’y a pas grand chose à faire au final.

Je te laisse l’essayer, sisi, download, unzip ./ , tu en as pour 5 minutes dont 2 secondes pour le démarrer.

Ca se passe là:

Réflexion: il n’aura fallu qu’un an pour sortir cette version finale de JBoss Application Server 7, certifiée Java EE6 Web Profile. Un an ce n’est rien lorsque l’on connait la complexité d’un tel projet, la variété de compétences requise pour le mener à bien. Ca fait réfléchir sur l’organisation projet, sa gestion, la gestion des ressources, des compétences. Je ne peux m’empêcher de comparer l’évolution de ce projet avec les expériences projet de mes postes précédents, en interne ou en tant que prestataire. Ma conclusion est radicale et sans appel mais je la garde pour moi, je suis fier d’être un RedHat!

Hibernate Search: la cerise sur le gâteau

Posted in Persistance / Données by apatricio on juillet 15, 2009


Vous utilisez Hibernate? oui
Vous utilisez les annotations pour définir vos méta données? oui
Vous ne connaissez pas Hibernate Search? honte à vous!

R.O.I. HB-Search

Il y a des frameworks qui proposent des ROI assez impressionnants, Hibernate Search en fait partie.

Comme vous l’avez probablement deviné Hibernate Search permet d’implémenter un moteur de recherche fulltext efficace. Il s’appuie sur Lucene, Hibernate et les annotations.

Lucene est une technologie java d’indexation et de recherche très mature, aboutie et efficace. L’intérêt d’HB Search réside en son intégration avec Hibernate, il en résulte une facilité de mise en œuvre impressionnante.

Nous sommes régulièrement confronté au problème d’implémentation de moteur recherche dans nos applications d’entreprise. Plusieurs soucis:

  • niveau conception : nous sommes très forts pour proposer des formulaires de recherche ciblant toutes les données imaginables de nos modèles, allant parfois implémenter des formulaires de recherche comportant 36 champs. Le problème de ces formulaires étant leur inaccessibilité pour la ménagère de moins de 50 ans –> pour le grand public
  • niveau pertinence: nous savons être pertinents et précis sur des numériques, des dates, des booléens mais lorsque l’on nous demandes de prendre en compte les fautes d’orthographes ou les synonymes sur les chaînes de caractères, on se retrouve généralement démunie

Avec HB Search vous pouvez proposer à vos clients, pour un coût moindre, une ouverture vers un moteur fulltext user-friendly (typiquement champ de formulaire unique « à la google »). Ils seront agréablement surpris et n’auront aucun mal à élargir le spectre des spécifications pour consolider ce moteur.


Imaginez une classe Produit avec diverses propriétés de type String comme le libellé et la marque ou libellePrincipal et libelleSecondaire.

Vous souhaitez que la recherche cible ces deux propriétés.

Ci-dessous l’entité annotée comme vous en avez l’habitude:

public class Produit {

	private int codeProduit;

	private String libellePrincipal;

	private String libelleSecondaire;

Et effectuer une recherche, par exemple, via HQL:

javax.persistence.Query q =
		"select produit " +
		"from Produit produit " +
		"where produit.libellePrincipal = :param");
q.setParameter("param", "café");
List results = q.getResultList();

Méta données

Que faut-il ajouter pour que l’entité et ses 2 champs soient puissent être ciblées par le moteur fulltext?

public class Produit {

	private int codeProduit;

	private String libellePrincipal;

	private String libelleSecondaire;
} stipule que l’entité annotée peut être indexée. Grâce à cette annotation, l’intégration Lucene/Hibernate est activée.

Parmi tant d’autres fonctionnalités gérées, l’indexation automatique vous simplifie la vie: lorsque vous agissez sur une entité de ce type, l’index lucene est automatiquement géré. déclare qu’une propriété est indexée. L’annotation propose divers leviers pour définir comment la propriété est indexée. Pour le moment appliquons le paramétrage par défaut.

Plutôt facile non? Attardons nous maintenant à l’aspect API

API de recherche

Avant de commencer, notez que des APIs équivalentes existent pour la session Hibernate.

Ici, plusieurs étapes sont nécessaires. Il faut d’abord obtenir un EntityManager fulltext, puis créer une requête Lucene. Enfin, la création d’une requête de recherche JPA depuis la requête Lucene nous permettra de retomber sur une API familière et pratique pour manipuler les entités retournées par la recherche.

Voici ce que ça donne:

// expression littérale de la requête Lucene</pre>
String searchQuery = "cafe~"; fullTextEm =
SearchFactory sf = fullTextEm.getSearchFactory();

// Construction d'un QueryParser, définition du champ par défaut
// récupération de l'analyseur lié à l'entité
org.apache.lucene.queryParser.QueryParser parser = new QueryParser(
	sf.getAnalyzer( Produit.class )

// construction de la requête lucene luceneQuery = parser.parse(searchQuery);

// création de la requête JPA fulltext ftq =
	fullTextEm.createFullTextQuery(luceneQuery, Produit.class);

// exécution de la requête
List results = ftq.getResultList();

La subtilité ici réside en la recherche Lucene «~cafe ». Le tilde active une recherche par approximation. Ce type de recherche permet d’éviter les problèmes d’accent et de typo que l’on rencontre très souvent. De même si les utilisateurs saisissent des fautes d’orthographes, cette recherche s’en sortira facilement.

Bien plus de fonctionnalités

Cette article n’a pas l’ambition de couvrir toute la puissance d’Hibernate Search, simplement de démontrer la facilité et rapidité de mise en œuvre. L’exploitation d’un graph d’objet (et de ses associations) pour la recherche, la pondération de certains champs, la pertinence de la recherche sont possibles et faciles à utiliser.
Bien entendu, d’autres aspects doivent être pris en compte, notamment l’utilisation des analyseurs (approximation, phonétique, synonymes,…) et la gestion / maintenance des index.
Je vous recommande donc la lecture du guide de référence mais surtout du livre d’Emmanuel Bernard et John Griffin.


Teiid: les données que vous voulez à partir de celles dont vous disposez

Posted in Persistance / Données by apatricio on juin 12, 2009


On ne peut être plus clair: les données que vous voulez à partir de celles dont vous disposez.

Teiid vous permet d’agréger plusieurs sources de données en une seule. Imaginez plutôt, vous disposez de 2 bases de données relationnelles, 3 services web et de fichiers plats, vous mettez tout dans le mixeur et à la fin vous ne manipulez plus qu’une seule source de données.

Si l’appli cliente est en Java, vous exploiterez cette source de données via JDBC ou encore mieux via Hibernate ou JPA puisque la dernière release incluse un dialect Hibernate.

Bien entendu, Teiid dispatchera chaque ordre vers les sources de données finales.

La force de Teiid réside, à mon sens en 3 points:

  • la maturité, Teiid est en fait fondé sur MetaMatrix
  • l’outillage, tout simplement impressionnant
  • une liste de fonctionnalités bien plus riche et subtile que le résumé de cet article

Rendez-vous au plus vite le blog et sur les sites Teiid et Teiid designer.

Darwin et Java, prochaine étape de l’évolution des applications

Posted in Actu / Anecdote by apatricio on juin 10, 2009

Année 2000, ahhh je me souviens le bon vieux temps où je crachais sur les EJBs et prônais le standalone efficace en développant une allergie hypodermique à tout ce qui se rapprochait d’un serveur d’app.

On développait avec JSP, struts et hibernate, le tout en stateless bien sûr, et on était contents, super contents. Grâce à struts, on passait 1h45 heure au lieu de 2 à concevoir notre JSP, la plugger à notre logique de navigation, coder nos validations de surface. Ahhh ce que c’était chia….

Tous ces aspects m’ont vite persuadé de me focaliser sur la persistance, le développement côté serveur, bref TOUT sauf les vues.

Quelques années ont passé, EJB3 est arrivé et j’ai retrouvé les beans session et le stateful et toute sa puissance. C’est Seam, un next generation framework imaginé par Gavin King, qui a d’ailleurs redoré le blason du stateful.

Les annotations nous ont délivrés de l’enfer du XML et struts, après tant de bons et loyaux services, a doucement passé la main à JSF et là… c’est le bonheur surtout avec RichFaces.

J’espère avoir assez de temps libre pour partager des avis/exemples sur toutes ces technologies, EJB3, JPA, Seam, RichFaces mais aussi Hibernate Search qui marquent un pas décisifs dans le monde des applications Java.