Récemment, une énième discussion a enflammé les esprits sur les forums techniques. Vous savez bien, c’est une discussion qui démarre sur l’état de l’art et qui se termine en considérations sans fins sur les qualités comparées avec un “vieux langage” que-sur-des-cas-précis-il-ne-sera-jamais-dépassé…

C’est un fait que l’écosphère Java souffre actuellement d’une offre pléthorique (Struts/Stripes, Tapestry, . . . → Lire la suite: Java est-il trop “serré” ?]]>

Récemment, une énième discussion a enflammé les esprits sur les forums techniques. Vous savez bien, c’est une discussion qui démarre sur l’état de l’art et qui se termine en considérations sans fins sur les qualités comparées avec un “vieux langage” que-sur-des-cas-précis-il-ne-sera-jamais-dépassé…

C’est un fait que l’écosphère Java souffre actuellement d’une offre pléthorique (Struts/Stripes, Tapestry, JSF, Spring MVC, GWT, JavaFX… j’ai la tête qui tourne) et redondante (cf. débats actuels Java EE 6 vs. Spring 3.x ou la foule des portails, GED ou ESB apparus). Il est vrai aussi que :

1. les débutants sont mal formés, notamment sur les paradigmes OOP, AOP et SOA
2. les développeurs expérimentés s’épuisent à passer d’un framework à l’autre
3. les architectes n’ont pas le temps d’évaluer les versions qui sortent en permanence

Sans parler des projets tellement évolutifs qu’ils embarquent plusieurs technologies Web Services en même temps ou pâtissent de toutes sortes de dettes techniques, faute de recevoir une maintenance planifiée…

Mais a contrario, en Java les standards évoluent tellement lentement qu’on leur préfère des solutions alternatives à forte obsolescence. On en est là. Avouez que c’est quand même dommage de faire preuve d’immaturité à cet âge ! De mon temps (hum) les bonnes idées étaient simplement reprises et transcendées au sein de la “meilleure” communauté créée.

Mais aujourd’hui il semblerait que notre industrie soit en guerre. jBoss vs Spring, Adobe vs Google, Hudson vs Jenkins… Faut-il pour autant prêcher la dictature comme remède à l’anarchie ? Nous ne voulons pas devenir .Net, si ? Bref, j’exagère (à peine).

Pourquoi le monde Java en est-il arrivé là ?

Selon moi, c’est à cause de son succès, justement. Le niveau d’activité de la communauté me semble tout à fait remarquable, notamment dans l’Open Source, mais pas que. Le revers de la médaille, c’est qu’un si grand nombre d’intervenants implique le ralentissement des prises de décision, favorisant ainsi l’adoption de solutions spécifiques ou inachevées.

Avant, c’était mieux (n’est-ce pas ?). Un serveur d’application Tomcat et quelques spin-off, un peu d’injection et de bonnes pratiques ORM et c’est parti pour le framework léger. Un IDE sympa, avec quelques plugins utiles. En plus, tout ça gratos ! Et l’enthousiasme du fait main se répandait dans les entreprises à la faveur des SCM. Ajoutez à cela les annotations, et l’on a pu croire un temps que nous serions productifs.

Bon… ça n’a pas vraiment suffit. N’est-ce pas ? Alors il y a eu Maven, l’intégration continue et même l’agilité. Et BOUM ; peut-être que ça marche trop bien, finalement : tout le monde s’est mis à parler/publier en même temps, la tête dans le guidon. Une vraie course à la nouvelle version.

Mais alors qu’est-ce qu’on va FAIRE (Mon Dieu) ?

Nous avons une responsabilité, en tant que communauté et en tant que professionnels. Cette responsabilité est de suivre un cap réfléchi pour assurer à nos utilisateurs et à nos clients une certaine forme de pérennité. Je ne parle pas de 10 ou 15 ans, bien sûr. En technologies de l’information et de la communication (comme on dit), c’est l’éternité ! Et c’est enfoncer une porte ouverte que de proposer un socle commun stable. Nous SAVONS ce qu’il nous faut. La question est COMMENT l’obtenir.

Et bien je pense personnellement que la République des Experts, c’est fini. Il nous faut une Démocratie Participative (notez les majuscules, je vous prie). Nous vivons actuellement une période transitoire qui pourrait très bien aboutir à un verrouillage par quelques grands acteurs (parmi Adobe, Google, jBoss ou d’autres), au détriment de la créativité et de la réactivité. Pour éviter cela, je pense que les développeurs devraient pouvoir influer sur les orientations du marché pas seulement par plébiscite, a posteriori, mais aussi en amont sur la base d’une information éclairante.

The Apache Software Foundation nous a montré la voie (par le truchement de l’incubation et d’un processus électif). Mais la méritocratie (qui a dit bureaucratie ?) n’est pas suffisante. Avez-vous compté le nombre de projets que la fondation héberge, récemment ? Là aussi, le débordement fait plus que nous guetter : il nous attend au tournant. Certaines idées méritent plus qu’un avis technique, il leur faut un coup de pouce (comme dans l’expression “Je poussoies”, bien sûr) afin de leur assurer l’effort requis. Et chacun, comme pour une primaire politique, devrait pouvoir donner sa voix sur la teneur des projets à privilégier.

Nous n’avons pas besoin d’une dizaine de bases NoSQL ; nous avons besoin d’une (aller, deux) solutions qui fonctionnent et garantissent une réponse à une problématique réelle (mais je garde pour moi mon opinion, concernant cet exemple précis). Les outils existent, je regarde vers GitHub (en tant que plateforme collaborative, peu importe que le support soit Git ou SVN, au fond). Nous savons fédérer la motivation ; mais il nous reste à exprimer l’intérêt plus tôt au cours du processus de développement afin d’éviter le gâchis actuel qui consiste à jeter nos forces dans des projets concurrents, parfois complètement équivalents, mais dont personne ne veut abandonner la paternité.

Un processus démocratique, ouvert, devrait permettre aux solutions d’avenir de recevoir suffisamment de moyens pour percer, prendre le temps de se stabiliser, et enfin s’imposer. Non pas sur une mode qui aurait duré, mais sur la qualité d’une réalisation ayant reçu toute l’attention nécessaire.

Au royaume du NoSQL, Apache Cassandra tient une place de choix

Apache Cassandra est une base de donnée distribuée conçue pour géer de larges volumes de données sur des grappes de serveurs d’entrée de gamme. Son architecture complètement distribuée lui permet de jouir d’une scalabilité horizontale linéaire et d’une forte tolérance aux pannes (‘high . . . → Lire la suite: Ippevent Cassandra le 23 mai prochain]]>

Au royaume du NoSQL, Apache Cassandra tient une place de choix

Apache Cassandra est une base de donnée distribuée conçue pour géer de larges volumes de données sur des grappes de serveurs d’entrée de gamme. Son architecture complètement distribuée lui permet de jouir d’une scalabilité horizontale linéaire et d’une forte tolérance aux pannes (‘high availability’).

Lors de cet Ippevent, deux intervanant viendront nous parler de cet outil génial.

Tout d’abord Nicolas Romanetti de Jaxio qui nous fera un retour d’expérience sur ses mises en oeuvre de Cassandra, puis Sylvain Lebresne de Datastax éditeur spécialisé sur Cassandra viendra nous parler de l’architecture et des évolutions futures de la solution

Pour vous inscrire il vous suffit de cliquer sur le bouton ci-dessous

Çağatay est membre de l’expert group JSF, fondateur et développeur principal de PrimeFaces, et membre du comité de management d’Apache MyFaces. Il a animé de nombreuses conférences . . . → Lire la suite: Participez à une formation JSF2/PrimeFaces avec Çağatay Çivici, le fondateur de PrimeFaces !]]> Dans le cadre de son partenariat avec PrimeFaces , Ippon Technologies organise les 20, 21 et 22 juin une formation exceptionnelle dans ses locaux, avec Çağatay Çivici !

Çağatay est membre de l’expert group JSF, fondateur et développeur principal de PrimeFaces, et membre du comité de management d’Apache MyFaces. Il a animé de nombreuses conférences à travers le monde, en particulier Jax, W-Jax, SpringOne, Jazoon, JSFDays, JSFSummit, ainsi que de nombreux JUGs. Il est également auteur et relecteur technique de plusieurs livres traitants du développement d’applications Web avec Java et JSF. En tant que formateur, Çağatay a formé plus de 300 développeurs sur les technologies Java EE, et tout particulièrement JSF.

Le descriptif détaillé de la formation est disponible sur le site d’Ippon Technologies : http://www.ippon.fr/formation/primefaces

Concernant les détails pratiques :

• Le lieu : la formation aura lieu dans les locaux d’Ippon Technologies à Levallois-Perret. Nous sommes équipés de iMacs dernière génération, mais vous pouvez venir également avec votre propre matériel (BYOD).
• Le prix : 1650 Euros HT pour les 3 jours, incluant les repas de midi

Pour vous inscrire à cette formation, ou pour obtenir de plus amples informations, n’hésitez pas à nous envoyer un e-mail à formation@ippon.fr ou à nous téléphoner au + 33 (0)1 46 12 48 48 .

Ce concours consistait à finaliser et à débugger une application complète, basée sur HTML5+Spring+Cassandra. Du vrai code, disponible sur GitHub, pour une vraie application !

Cette application a été spécialement développée par votre humble serviteur, ainsi que . . . → Lire la suite: Résultat du concours “Tatami” pour Devoxx France]]> Ippon Technologies a lancé il y a 3 semaines un grand concours de code, portant sur l’application Tatami.

Ce concours consistait à finaliser et à débugger une application complète, basée sur HTML5+Spring+Cassandra. Du vrai code, disponible sur GitHub, pour une vraie application !

Cette application a été spécialement développée par votre humble serviteur, ainsi que par mon collègue Thomas Escolan, que je tiens à vivement remercier pour son travail sur la partie HTML5.

Le jeu s’est terminé ce matin, il est donc temps de faire un bilan et d’annoncer les vainqueurs !

Bilan du jeu

Sur Github, nous avons eu 60 “watchers”, 46 “forks” et 18 “pull requests” : il est évident que ce jeu a été pour nous un grand succès.

Au final, nous avons eu une dizaine de participations intéressantes (que nous allons détailler ci-après), dont certaines étaient particulièrement avancées et créatives.

L’application a évolué de manière très notable, même s’il est parfois compliqué de pouvoir fusionner des modifications provenant de tous ces forks différentes.

L’un de nos objectifs futurs est de pouvoir terminer l’application, afin qu’elle soit rééllement utilisable, sachant qu’il n’existe pas de solution Open Source équivalente (à notre connaissance, le système qui s’en approche le plus est Yammer, qui bien entendu est un logiciel commercial).

Participations marquantes

Un fork “full Java EE”

Romain Manni-Bucau, commiter TomEE et OpenEJB, a fait un fork supprimant totalement Spring de l’application :

https://github.com/rmannibucau/tatami

Le code final fonctionne donc correctement sur TomEE, à quelques nuances près (en particulier la sécurité, qui en Java EE doit être configurée dans le serveur d’applications et non dans l’application, ainsi que le cache, qui a dû être codé spécifiquement), et cela nous a permis de faire des tests de performance très intéressants, entre deux stacks concurrentes :

• Jetty + Spring + Spring MVC REST
• Tomcat + OpenEJB + CXF

Le résultat initial étant très lié au serveur d’applications (Jetty faisant du NIO par défaut, il tenait nettement mieux la charge), après un peu de tuning Romain est arrivé aux statistiques suivantes, avec pour 1000 utilisateurs concurrents, sur une petite machine de bureau :

• Spring : 196.6 requêtes par seconde
• TomEE : 182.3 requêtes par seconde

Sachant que les serveurs et JMeter étaient tous sur la même machine, ces résultats sont bien entendu à prendre avec une pincée de sel…

Mais quoiqu’il en soit, nous pouvons en tirer les conclusions suivantes :

• Spring et TomEE tiennent la chargent de manière équivalente
• L’application tient facilement 3000 utilisateurs concurrents, avant que JMeter ne crashe : nous tenons donc extrêmement bien la charge, essentiellement grâce à Cassandra et au système de cache
• L’ajout d’un cache nous fait gagner environ 20% de requêtes/seconde, car on n’a plus à faire un accès réseau (local) vers Cassandra, et à sérialiser/déserialiser les données : Cassandra seul peut donc largement suffire en tant que cache distribué

Si vous voulez faire ces tests vous-mêmes, le jeu de test est disponible sur GitHub. Attention cependant, la version Spring a depuis pas mal évolué, l’ajout de nouvelles fonctionnalités devraient logiquement la faire ralentir un peu.

Enfin, pour ce qui est de la productivité et de la qualité des développements Spring vs Java EE, je vous laisse juges en lisant le code source :

• Le code Spring est nécessairement plus concis, car Spring propose plus de fonctionnalités en standard (c’est normal d’ailleurs, Spring s’appuyant sur Java EE pour l’améliorer)
• Le code “full Java EE” est plus standard (pas d’annotations Spring), en particulier sur la partie REST (pour l’injection de dépendances les deux codes utilisent le standard @Inject, les différences restent donc minimes)

Ajout de tests unitaires avec cassandra-unit

Jérémy Sevellec, l’auteur de cassandra-unit, a ajouté une suite complète de tests d’intégration utilisant (évidemment) cassandra-unit. C’est sans doute la contribution qui a le plus aidé à la qualité du code.

Jérémy a également fait preuve d’un excellent esprit de participation (ce qui compte au Judo !), vous pouvez donc voir ce travail dans cette pull request qui a été ajoutée au code du projet :

https://github.com/ippontech/tatami/pull/32

Utilisation d’un configuration Spring avec 0 ligne de XML

Gildas Cuisinier, bien connu des amateurs de Spring, nous a proposé une configuration Spring “0 XML”. La mode actuelle est de faire le moins de XML possible, mais d’un point de vue purement personnel je vous avoue trouver cette configuration moins lisible que son homologue XML.

Vous pouvez étudier son travail via cette pull request, elle aussi acceptée dans le projet :

https://github.com/ippontech/tatami/pull/36

Cependant, ce code s’est révélé relativement lent au démarrage, car il forçait l’application à scanner tout son classpath. Fabien Arrault (Ippon Technologies) nous a donc proposé cette pull request, qui réintroduit quelques lignes de XML et nous redonne les performances d’origine :

https://github.com/ippontech/tatami/pull/38

Utilisation de Spring Mobile et JQuery Mobile

L’une des amélioration à réaliser était de réaliser une interface “mobile” de l’application. Plusieurs personnes ont démarré cette fonctionnalité, en utilisant toutes :

• Spring Mobile pour savoir si l’utilisateur utilisait (ou non) un téléphone ou une tablette
• Les fonctionnalités de Spring MVC pour rediriger ensuite l’utilisateur vers une vue “standard” ou une vue “mobile”

Gildas Cuisinier en a proposé une première version qui a été intégrée dans le projet principal :

https://github.com/ippontech/tatami/pull/46

Utilisation de Spring Social

Spring Social est un sous-projet Spring permettant d’utiliser simplement les APIs des différents réseaus sociaux tels que Twitter, Facebook, etc…

L’un des objectifs du jeu était de connecter l’application à ces réseaux, à priori en utilisant Spring Social : malheureusement, c’est l’un des seuls objectifs qui n’a pas été entièrement finalisé.

Sam Bessalah en a certainement fait la version la plus aboutie, mais il ne l’a pas livrée à temps pour la date finale du jeu :

https://github.com/samklr/tatami

Gagnants

2ème place : François Descamps

François Descamps a contribué un nombre de pull requests impressionnant. Il gagne donc haut la main le trophée du fair play, car il a très régulièrement soumis son code pour qu’il soit intégré dans l’application d’origine.

En particulier (et de manière non exhaustive), il a :

• Refactoré le code JavaScript (mais précisons que ce refactoring ne fait pas l’unanimité du jury)
• Mis en place Elastic Search avec l’aide de David Martin (Ippon Technologies), pour pouvoir rechercher des utilisateurs et des tweets
• Ajouté une protection contre les attaques XSS avec JSoup et Bean Validation
• Et proposé de nombreux commits pour améliorer l’interface graphique et l’utilisabilité…

François gagne donc une place de 2 jours à Devoxx France !

1ère place : DuyHai Doan

DuyHai Doan a fait un fork particulièrement impressionnant. Le seul défaut de sa contribution étant qu’elle soit dans un fork tellement éloigné du master qu’il nous sera difficile de réintégrer ses modifications dans le code principal.

Mais à part cela, il a développé un très grand nombre de fonctionnalités, ce qui fait de son fork une version de l’application plus avancée que l’originale, malgré les commits de nombreux concurrents différents.

En particulier, il a :

• utilisé Hector Object Mapper pour améliorer la qualité de la couche repository (en utilisant au maximum JPA)
• utilisé Cassandra de manière intelligente pour proposer une recherche des utilisateurs sans utiliser Elastic Search (ou Lucene). Cependant, il n’a pas implémenté la recherche des Tweets (impossible à faire avec Cassandra), il a donc une solution plus simple que celle utilisant Elastic Search, mais moins complète
• mis en place ESAPI et Bean Validation pour protéger l’application des attaques XSS
• ajouté la librairie Thymeleaf comme moteur de templates HTML5
• codé une interface graphique riche en utilisant LESS CSS, en ajoutant de nombreuses nouvelles fonctionnalités (les profils utilisateurs), ainsi qu’en améliorant le design général de l’application
• réalisé une excellente couverture de tests en utilisant TestNG
• développé une version mobile très complète de l’application, avec Spring Mobile, LESS CSS, Jackson, HTML5. C’est le point principal qui a fait gagner DuyHai

DuyHai gagne donc une place de 2 jours à Devoxx France, ainsi qu’un Galaxy Tab !

Avant toute chose, commençons par définir . . . → Lire la suite: GWT et Spring Security : c’est possible]]> Beaucoup d’applications nécessitent la mise en oeuvre de règles de sécurité dans tout ou partie de leurs fonctionnalités. Lorsque GWT est utilisé comme framework de présentation, les choses ne sont pas aussi simples qu’avec un framework plus traditionnel, où la nature des échanges client-serveur est plus claire et contrôlée.

Avant toute chose, commençons par définir ce qui sera présenté sous la notion de sécurité. L’objet du billet est de proposer à une application GWT la possibilité de gérer l’authentification des utilisateurs et le contrôle des droits sur les fonctionnalités exposées par le serveur. Ne sont donc pas présentés les aspects relatifs à la protection contre des attaques (XSS, CSRF, injections…).

Particularités de GWT

Les mécanismes de communication client-serveur proposés par GWT sont multiples. Historiquement, GWT propose une approche bas niveau : le RequestBuilder ainsi qu’une approche plus haut niveau, orientée RPC, et justement nommée GWT-RPC. Plus récemment, soit depuis GWT 2.1, un nouveau protocole d’échange, toujours basé sur http, est apparu, souvent désigné par son interface phare : RequestFactory. C’est un protocole orienté donnée, mais toujours de type RPC.
Alors que RequestBuilder permet d’avoir accès aux caractéristiques des requêtes et réponses http (ajout de headers http, choix du verbe http à utiliser, …), les deux autres approches que sont GWT-RPC et RequestFactory se positionnent à un niveau d’abstraction plus élevé et masquent ou bloquent l’usage de toutes ces possibilités.
RequestBuilder reste une approche assez technique, souvent réservée à des besoins ponctuels précis, mais rarement répandue comme mécanisme global de communication avec les services exposés par le serveur. GWT-RPC et RequestFactory apportent une bien meilleure productivité (non sans autres coûts cependant…).

La partie sécurité illustrée dans ce billet va s’appuyer sur Spring Security pour implémenter les règles de sécurité. Le framework va apporter les facilités de gestion des droits, mode de connexion, déconnexion, … Les principes présentés resteraient les mêmes pour un autre framework de sécurité (Apache Shiro (http://shiro.apache.org/) par exemple) mais nécessiteraient bien sûr une adaptation du code.

Voici les fonctions importantes qu’il convient de traiter dans le cadre de la sécurisation d’une application :

• Authentification : quel type et à quel niveau ?
• Validation des droits de l’utilisateur : vérification des droits et prise en charge des refus d’accès
• Mécanisme de déconnexion, remember-me, …

Avant d’aborder ces points, il convient de se pencher sur le coeur du problème : qu’est ce qui rend une application GWT différente d’une application plus classique dans la gestion de la sécurité ?

La première différence notable est la sensibilité aux données retournées lors des appels aux services, principalement dans les cas d’utilisation reposant sur GWT-RPC ou RequestFactory. En effet, ces protocoles ne vont pas savoir interpréter les réponses classiques de Spring Security dans le cas d’une authentification nécessaire (traité classiquement par une redirection vers une page HTML contenant le formulaire de connexion) ou d’un refus d’accès à une ressource (redirection vers une page d’erreur 403 par exemple). Afin que ces protocoles soient éventuellement en mesure d’interpréter des messages correspondant à ces cas de figure, il leur faudra recevoir une réponse adaptée à leur format d’échange.
Il va donc être nécessaire au serveur de différencier une requête issue d’un composant GWT de toute autre requête, afin d’adapter sa réponse au besoin spécifique.

Un autre point important, qui concerne autant GWT-RPC que RequestFactory est la nature “RPC” de ces protocoles. Les URL qui seront appelées ne pourront pas (sauf effort supplémentaire coûteux et peu élégant) laisser présumer de l’action souhaitée coté serveur. Cette information appartient au “payload” de la requête. Et à moins de le décrypter (toujours possible, mais un peu coûteux) afin d’aller chercher cette information, il n’est pas possible d’appliquer une politique de sécurité basée uniquement sur un simple filtrage d’URL.

Mécanismes de Spring Security

Pour comprendre la proposition d’implémentation ci-après, il convient d’avoir à l’esprit quelques grands principes de fonctionnement de Spring Security.
Le framework Spring Security fonctionne par application d’un filtre (au sens Filter de la spécification Java Servlet) sur les requêtes reçues par l’application. Ce filtre gère en fait une chaîne ordonnée de sous filtres (au sens Spring Security cette fois), et agit donc comme une sorte de point d’entrée vers un ensemble de contrôles séquentiels appliqués aux requêtes. Chacun de ces contrôles est dédié à une vérification ou action particulière.

Autre point important concernant Spring Security : les différentes façons de définir et contrôler les droits. Spring Security propose une première approche basée sur des règles de filtre d’URL : il est possible d’associer à des patterns d’URL des privilèges requis pour y accéder (ex. : “/admin/**” -> “ROLE_ADMIN”).
Par ailleurs, en substitution ou en complément selon les cas, il est aussi possible d’utiliser une autre approche, par instrumentation des classes de l’application afin de leur appliquer des restrictions d’usage. Par configuration XML ou par annotation (beaucoup plus simple), un service pourra alors voir ses méthodes décorées de notions de droits d’accès (ex. : @Secured(“ROLE_ADMIN”) sur une méthode public boolean delete(MyResource resource));

Ces deux notions (fonctionnement par application d’une chaîne de filtres sur les requêtes ainsi que les deux modes de déclaration des contraintes de sécurité par patterns sur des URL d’une part ou instrumentation d’autre part) vont vous permettre de mieux comprendre ce qui suit.

Commençons maintenant le tour d’horizon des cas d’utilisation relatifs à la sécurité.

La toolbox

Afin de simplifier la création de la couche de sécurité, l’approche décrite ci-après s’appuie sur une petite librairie et une application “sample”, que vous trouverez ici : https://github.com/dmartinpro/gwt-security/

L’authentification

Comme vous le savez sûrement, l’authentification peut être réalisée de plusieurs façons. La plus courante consiste à utiliser un formulaire HTML afin de collecter dans la plupart des cas un identifiant accompagné d’un mot de passe. Le tout en général transite via une connexion sécurisée vers le serveur (SSL). Une autre approche, plus souvent utilisée pour sécuriser des services “techniques” (web service, API http), utilise l’authentification de type BASIC, toujours de façon sécurisée (clarté des informations oblige avec BASIC…). Il existe par ailleurs d’autres types (DIGEST, par certificat, indirecte par SSO, custom).
Le mode d’authentification le plus ergonomique pour un utilisateur est celui par formulaire. Il permet d’offrir une présentation personnalisée, intégrée graphiquement à l’application, … des qualités qu’une popup pour une authentification BASIC ne propose pas.
Dans le cas d’une application dont la couche de présentation est écrite en GWT, deux choix s’offrent alors : le formulaire d’authentification est-il aussi écrit avec GWT ou bien est-il proposé séparément sur une page dédiée ?

Illustrons le cas le plus intéressant : le formulaire est codé avec GWT (et donc mieux intégré au sein de l’application). Ce formulaire va être accédé de deux façons :

• Volontaire : l’utilisateur affiche le formulaire pour y saisir les informations
• Involontaire : l’utilisateur tente d’accéder à une ressource protégée mais n’est pas encore connecté : il est redirigé vers le formulaire.

Dans les deux cas, il devra poster les informations saisies vers un “service” particulier (un filtre au sens Spring Security : UsernamePasswordAuthenticationFilter). Le code GWT lié au formulaire pourra s’appuyer sur RequestBuilder (voir com.gwtsecurity.client.LoginHandler) pour cela.
Le filtre UsernamePasswordAuthenticationFilter délègue à deux objets le soin de gérer les cas d’authentification réussie et en échec. Il est important d’ores et déjà de savoir répondre au composant GWT sous une forme intelligible spécifique, distincte du cas nominal d’un formulaire traditionnel.
Afin de répondre à ce besoin particulier, deux classes sont donc créées :
GwtSavedRequestAwareAuthenticationSuccessHandler et GwtSavedRequestAwareAuthenticationFailureHandler
L’identification des requêtes GWT doit se faire sur un discriminant simple. L’approche proposée est de s’appuyer sur un header http spécifique. RequestBuilder va donc ajouter à la signature de la requête le header “X-GWT-Secured=true”.
Dans le cas d’une requête http issue du composant RequestBuilder ainsi configuré, les deux classes pourront ainsi adapter leur réponse en retournant des structures simples à interpréter (une simple chaîne JSONdans un cas, et une réponse avec un “status code” explicite dans l’autre).

Dans le cas d’un accès dit “involontaire”, il convient de venir se greffer sur la classe ExceptionTranslationFilter de Spring Security. Cette classe s’appuie sur un “AuthenticationEntryPoint” pour proposer l’ “accès” à la méthode d’authentification requise. Dans le cas d’un formulaire, c’est LoginUrlAuthenticationEntryPoint qui se charge d’effectuer une redirection vers la page du formulaire.
Une telle redirection vers une page HTML contenant le formulaire d’authentification ne serait pas comprise par le composant GWT appelant et sera difficilement exploitable.
Aussi, un nouvel objet de type AuthenticationEntryPoint va devoir savoir lui aussi faire la distinction entre une requête issue d’un composant GWT et une requête autre et répondre dans le cas d’une requête issue de GWT quelque chose d’interpretable.
C’est le rôle que va jouer la classe GwtAwareAuthenticationEntryPoint en produisant une réponse JSON à toute requête reconnue comme issue de GWT. Le cas échéant, elle déléguera à LoginUrlAuthenticationEntryPoint.
La classe ExceptionTranslationFilter gérant aussi les exceptions de type AccessDeniedException, nous avons ainsi aussi la matière pour prendre en compte les cas de privilèges insuffisants du paragraphe suivant.

Contrôle des droits d’accès

Comme évoqué plus haut, le contrôle des droits d’accès ne peut pas se faire sur la simple base d’un filtre sur les URL. A ce niveau, seule une sécurité très macroscopique peut éventuellement trouver place (exemple : “il faut être connecté pour accéder à cette ressource”). Dès lors qu’on souhaite avoir un contrôle plus fin, du type : la suppression de la ressource X requiert un privilège “DELETE_RESOURCE” alors que sa consultation ne requiert que “GET_RESOURCE”, il convient de trouver une approche alternative plus fine.
Spring Security propose deux façons de procéder pour définir et contrôler les droits. Comme évoqué, l’approche par simple application d’un filtre sur l’URL est insuffisante sur des appels de type RPC. Par contre une sécurisation des services par instrumentation du code permet de répondre à ce problème d’ “obfuscation” de l’action demandée.

Comme vu précédemment, en se greffant sur ExceptionTranslationFilter, il est simple de prendre en compte le cas d’un accès refusé pour manque de privilège (réalisé aussi par la classe GwtAwareAuthenticationEntryPoint).
Ce qui reste à présenter maintenant, c’est la mécanique d’interception de ces réponses dans le code GWT, que cela soit dans le cas d’un appel GWT-RPC ou dans le cas d’un appel via RequestFactory.
Les deux approches partagent le même concept : un callback spécialisé va prendre en charge l’interprétation de ces réponses. Dans le cas de GWT-RPC, c’est la classe SecuredAsyncCallback qui va s’en charger, et SecuredReceiver pour RequestFactory.
Dans les deux cas, les méthodes onFailure() vont traquer une réponse liée à la sécurité et la gérer, sinon déléguer le traitement de l’erreur à une nouvelle méthode onServiceFailure() qui remplace le onFailure() par défaut.
Le code, pour un appel GWT-RPC, devient alors :

@UiHandler("gwtRPCButton")
public void onRpcButtonClick(ClickEvent e) {
 ApplicationResourcesFactory.getSimpleService().getData(new SecuredAsyncCallback<String>() {
   public void onServiceFailure(Throwable caught) {
     // Show the RPC error message to the user
     DialogBox dialogBox = new DialogBox();
     dialogBox.center();
     dialogBox.setModal(true);
     dialogBox.setGlassEnabled(true);
     dialogBox.setAutoHideEnabled(true);
     dialogBox.setText("Remote Procedure Call - Failure");
     dialogBox.show();
   }
   public void onSuccess(String result) {
     DialogBox dialogBox = new DialogBox();
     dialogBox.center();
     dialogBox.setModal(true);
     dialogBox.setGlassEnabled(true);
     dialogBox.setAutoHideEnabled(true);
     dialogBox.setText(result);
     dialogBox.show();
   }
 });
}

Autres fonctionnalités

Parmi les autres fonctionnalités, on peut ne peut pas oublier la déconnexion. Elle est tout aussi utile que la connexion et ne pas la proposer est une potentielle faille.
Spring Security propose un filtre simple pour répondre à ce besoin. Il suffit d’appeler une URL particulière, au besoin personnalisable, pour détruire le contexte de sécurité. Cela fonctionne très bien avec une authentification par formulaire ou par cookie (remember me). Par contre, une authentification de type BASIC (par exemple) sera automatiquement récréée à la prochaine requête et seule une fermeture du navigateur, en plus de ce mécanisme (à cause du potentiel cookie du remember me), peut avoir raison de l’authentification (à noter qu’il existe une autre approche moins radicale, mais aussi moins officielle, que la fermeture du navigateur, que je ne documenterai pas ici).
Afin de supporter cette fonction de déconnexion, il convient donc de créer un composant GWT dont la responsabilité est la création d’une requête http pointant sur cette URL de déconnexion.
Rien de plus simple avec RequestBuilder.Voir pour cela le code de la classe com.gwtsecurity.client.ui.LogoutButton.

L’option souvent associée à l’authentification “classique” est la fonctionnalité de “remember me”. Cette option permet de stocker dans un cookie une information qui va permettre lors d’une visite ultérieure, et même après une expiration de session sur le serveur (c’est l’intérêt d’ailleurs), de restaurer un contexte de sécurité. Cette option est très intéressante, d’autant plus avec les applications GWT qui favorisent le travail déconnecté (la richesse locale de l’application permet de travailler sans interagir forcement avec le serveur).
Bonne nouvelle : il n’y a rien à faire de spécifique pour supporter cette fonctionnalité avec GWT, alors autant en faire usage. Il s’agit donc d’ajouter la configuration nécessaire à Spring Security pour activer cette fonctionnalité.

Assemblage du tout

Cette configuration globale de la sécurité pour GWT nécessite quelques ajustements coté Spring Security. La configuration par défaut proposée par le namespace Spring Security ne peut plus suffire et il faut donc déclarer “à l’ancienne” la sécurité. Rien de compliqué lorsqu’on a cerné les responsabilités de chaque composant et le fonctionnement global, mais cela peut donner quelques mots de tête au démarrage. La configuration illustrée dans l’application d’exemple peut servir de base : /gwt-security-sample/src/main/resources/META-INF/spring/applicationContext-security.xml

Conclusion

La solution présentée mérite sûrement des améliorations ou adaptations (je vous invite à forker le projet), mais elle pose quelques bases qui pourront vous aider rapidement à mettre en place les composants nécessaires à la sécurisation de votre application.

Par ailleurs, si vous souhaitez approfondir le domaine de la sécurité dans les applications Java, je vous invite à (re)consulter le livre blanc sur le sujet : http://www.ippon.fr/livres-blancs.

Les deux grands . . . → Lire la suite: Google fait les cartes, Spring fait le REST]]> La cartographie est maintenant utilisée communément sur le Web. On ne peut plus consulter un site marchand sans pouvoir calculer son itinéraire jusqu’au point de vente, se renseigner sur un pays sans pouvoir explorer sa géographie, parfois même faire une sortie jogging ou vélo sans consulter ultérieurement son parcours sur une carte…

Les deux grands fournisseurs de cartographie sont actuellement Google avec sa Google Maps API et Microsoft avec Bing Maps. La plupart du temps, leur utilisation passe par du code Javascript exécuté côté client. Pourtant, il est parfois nécessaire de faire des traitements de géolocalisation côté serveur. Pour cela, les deux fournisseurs ont prévu une API de type REST. La suite de cet article ne s’intéressera plus qu’au monde “Google” et à son API, capable de générer une réponse de type XML ou JSON.

Be API avec le REST de Google !

Les principes de base

Pas de grosse surprise pour effectuer une requête géographique : on reste sur des principes REST classiques, avec une requête pour effectuer une géolocalisation inversée (à partir d’une adresse postale) du type :

http://maps.googleapis.com/maps/api/geocode/xml?address=90+rue+Baudin+92300+Levallois+Perret&sensor=false

Cette requête, qui peut être jouée directement sur un navigateur, permet de récupérer un message XML du type :

<GeocodeResponse>
  <status>OK</status>
  <result>
    <type>street_address</type>
    <formatted_address>90 Rue Baudin, 92300 Levallois-Perret, France</formatted_address>
    <address_component>
      <long_name>90</long_name>
      <short_name>90</short_name>
      <type>street_number</type>
    </address_component>
    <address_component>
      <long_name>Rue Baudin</long_name>
      <short_name>Rue Baudin</short_name>
      <type>route</type>
    </address_component>
    <address_component>
      <long_name>Levallois-Perret</long_name>
      <short_name>Levallois-Perret</short_name>
      <type>locality</type>
      <type>political</type>
    </address_component>
    <address_component>
      <long_name>Hauts-de-Seine</long_name>
      <short_name>92</short_name>
      <type>administrative_area_level_2</type>
      <type>political</type>
    </address_component>
    <address_component>
      <long_name>&#xCE;le-de-France</long_name>
      <short_name>IdF</short_name>
      <type>administrative_area_level_1</type>
      <type>political</type>
    </address_component>
    <address_component>
      <long_name>France</long_name>
      <short_name>FR</short_name>
      <type>country</type>
      <type>political</type>
    </address_component>
    <address_component>
      <long_name>92300</long_name>
      <short_name>92300</short_name>
      <type>postal_code</type>
    </address_component>
    <geometry>
      <location>
        <lat>48.8989222</lat>
        <lng>2.2877605</lng>
      </location>
      <location_type>RANGE_INTERPOLATED</location_type>
      <viewport>
        <southwest>
          <lat>48.8975800</lat>
          <lng>2.2864066</lng>
        </southwest>
        <northeast>
          <lat>48.9002780</lat>
          <lng>2.2891046</lng>
        </northeast>
      </viewport>
      <bounds>
        <southwest>
          <lat>48.8989222</lat>
          <lng>2.2877507</lng>
        </southwest>
        <northeast>
          <lat>48.8989358</lat>
          <lng>2.2877605</lng>
        </northeast>
      </bounds>
    </geometry>
  </result>
</GeocodeResponse>

Le message résultat est immédiatement compréhensive à un esprit humain. C’est sans doute pour cela qu’il n’est absolument pas documenté par Google, qui ne fournit pas même un XSD… 

REST ou JSON ?

Google préconise plutôt l’utilisation du service JSON.

JSON est clairement une notation beaucoup plus compacte que le verbeux XML et donc plus efficace. Cependant, elle n’offre pas tout l’attirail de XML, notamment en ce qui concerne la description des signatures de service et le contrôle des formats des messages. J’ai toujours tendance à privilégier XML pour les échanges de serveur à serveur et JSON pour les interactions internes à un système (interrogation AJAX d’un client web sur son serveur par exemple).

On est ici sur des échanges serveur à serveur, donc va pour le XML !

Comment conjuguer REST et Spring

La classe RestTemplate

Spring fournit la classe RestTemplate, qui elle-même fournit des méthodes de haut niveau pour invoquer les 6 méthodes principales du protocole HTTP. Elle simplifie énormément la programmation de la partie cliente d’un appel REST en gérant toute la plomberie habituelle liée à l’utilisation du protocole HTTP et la conversion des objets Java.

La lecture de la doc Spring conduit vite à la constatation que l’appel du service Google maps précédent peut se faire sous la forme :

	restTemplate.getForObject(
		"http://maps.googleapis.com/maps/api/geocode/xml?address={address}&sensor=false",
		String.class,"90 rue Baudin, 92300 Levallois Perret");

L’encapsulation de JAXB 2

Le code suivant est simple et de bon aloi, mais ne résout pas la problématique du mapping du résultat (ici un flux XML) vers le graphe d’objets Java.

Heureusement, et c’est là qu’entre la magie du RESTTemplate, il peut être configuré à l’aide d’un marshaller fourni par Spring :

org.springframework.oxm.jaxb.Jaxb2Marshaller

Rien de plus à ajouter que de référencer cette classe, à la fois comme marshaller et comme unmarshaller pour retrouver son modèle métier directement mappé sur le flux XML ! C’est de la pure magie, mais c’est bon !

Un petit projet vaut mieux qu’un long post de blog…

La Mise en place Maven

Il n’existe pas à ma connaissance d’archetype tout prêt pour faire du Spring. Pour notre exemple, nous partirons donc d’un archetype simple, en tapant la commande suivante :

 mvn archetype:generate \
  -DarchetypeArtifactId=maven-archetype-quickstart \
  -DgroupId=fr.ippon.gmap \
  -DartifactId=restgmap \
  -Dversion=1.0-SNAPSHOT

On obtient ainsi un projet restgmap, dans lequel nous allons nous empresser de modifer le fichier pom.xml pour notamment ajouter les dépendances à Spring :

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.10</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.apache.log4j</groupId>
      <artifactId>com.springsource.org.apache.log4j</artifactId>
      <version>1.2.15</version>
    </dependency>
    <dependency>
      <groupId>org.apache.commons</groupId>
      <artifactId>com.springsource.org.apache.commons.logging</artifactId>
      <version>1.1.1</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>org.springframework.core</artifactId>
      <version>${spring.version}</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>org.springframework.test</artifactId>
      <version>${spring.version}</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>org.springframework.context</artifactId>
      <version>${spring.version}</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-oxm</artifactId>
      <version>${spring.version}</version>
    </dependency>
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>org.springframework.web</artifactId>
      <version>${spring.version}</version>
    </dependency>
  </dependencies>
  <properties>
    <spring.version>3.0.5.RELEASE</spring.version>
  </properties>
  <repositories>
    <repository>
      <id>com.springsource.repository.bundles.release</id>
      <name>SpringSource Enterprise Bundle Repository - SpringSource Bundle Releases</name>
      <url>http://repository.springsource.com/maven/bundles/release</url>
    </repository>
    <repository>
      <id>com.springsource.repository.bundles.external</id>
      <name>SpringSource Enterprise Bundle Repository - External Bundle Releases</name>
      <url>http://repository.springsource.com/maven/bundles/external</url>
    </repository>
  </repositories>

La création du modèle

L’analyse de la réponse fournie lors d’une interrogation du service de géolocalisation permet assez facilement de construire un modèle objet comme suit :

Ce modèle en poche, les annotations JAXB se font très facilement même s’il aurait été plus simple de faire tout cela à partir d’une XSD, directement fournie par Google…

On a par exemple la classe Geometry comme suit :

package fr.ippon.gmap.model.gmap;

import javax.xml.bind.annotation.XmlElement;

public class Geometry {
    @XmlElement
    private GeoPosition location;
    @XmlElement
    private Viewport viewport;
    @XmlElement
    private Viewport bounds;

    public GeoPosition getLocation() {
        return location;
    }
}

Pour avoir toutes les informations sur les classes annotées, vous pouvez vous référerez au code qui est disponible sur GitHub à l’adresse : https://github.com/bpinel/restgmap

Le service et son test unitaire

Le reste du code est tout ce qu’il y a de plus standard. Et je vous laisse découvrir le service et les tests unitaires dans le projet git.

Depuis son apparition, PrimeFaces est dans la pratique en train de supplanter les autres bibliothèques de composants JSF, grâce à sa simplicité . . . → Lire la suite: Ippon Technologies est partenaire PrimeFaces]]> Chez Ippon Technologies, nous aimons les solutions standards, efficaces et Open Source. C’est donc tout naturellement que nous avons fait le choix de PrimeFaces comme librairie de composants JSF chez plusieurs de nos clients.

Depuis son apparition, PrimeFaces est dans la pratique en train de supplanter les autres bibliothèques de composants JSF, grâce à sa simplicité et à ses performances. Cette recherche Google Trends en est la meilleure illustration.

Nous apprécions en particulier :

• La légèreté et la performance de l’interface graphique
• Le fait d’utiliser JQuery, ce qui permet facilement de personnaliser l’interface
• La rapidité des développements, grâce à des jeux de composants très bien conçus
• Son excellente intégration avec Spring Web Flow, ce qui permet de réaliser des applications complexes (utilisant en particulier un persistence context étendu afin de gérer les conversations)
• Sa communauté très dynamique
• Le respect des standards, qui reste une garantie de pérennité pour nos clients

Par conséquent, nous avons décidé de nouer un partenariat avec Prime Technoloji, la société développant PrimeFaces. Comme vous pouvez le constater, aussi bien sur la page partenaire d’Ippon Technologies que sur la page partenaire de PrimeFaces, Ippon Technologies est aujourd’hui la seule société en France proposant :

• Les formations officielles et certifiantes PrimeFaces, conçues par Çağatay Çivici en personne!
• Le support officiel PrimeFaces

Et bien entendu nous proposons toujours nos services de conseil et d’architecture autour de Java EE, JSF et donc PrimeFaces !

Les IMDG font partie du paysage depuis quelques temps mais on les imagine réservés aux applications complexes telles que celles que l’on rencontre dans la . . . → Lire la suite: Livre blanc Ippon : Grilles de données mémoire]]> Plus que de simples caches, pas tout à fait des solutions NoSQL, surtout pas des bases de données mémoire, la définition des In memory Data Grids (IMDG) n’est pas simple.

Les IMDG font partie du paysage depuis quelques temps mais on les imagine réservés aux applications complexes telles que celles que l’on rencontre dans la finance, ou alors réservés à des traitements de masse.

Or ce n’est pas vraiment le cas lorsque l’on regarde les cas d’application les plus courants, en effet elles peuvent répondre aux besoins suivants :

• Performances (améliorer les performances des accès aux données, soulager une source de données).
• Disponibilité (augmenter la disponibilité d’une application).
• Scalabilité (assurer une scalabilité horizontale).

Ce livre blanc sur les IMDG Java en donne une définition ainsi que leurs principales caractéristiques. Il présente les cas d’utilisation les plus courants, les bonnes pratiques ainsi que les écueils que l’on peut rencontrer lors de la mise en œuvre de ce type de solution.

De plus il présente une étude de trois produits les plus répandus du marché :

• Oracle Coherence
• JBoss Infinispan
• VMWare Gemfire

Si vous souhaitez approfondir le sujet ou tout simplement le (re)découvrir, vous pouvez télécharger le livre blanc dans la rubrique dédiée sur le site d’Ippon Technologies.

Et bien évidement ce blog est un lieu d’échanges, j’attends donc avec impatience vos remarques et réactions suite à votre lecture.

La date fatidique approchant, nous sommes en train de préparer activement nos interventions :

– rodage de l’Agile Game “Lego4Scrum” dans nos agences de Paris/ Levallois et Nantes (dont notamment une session à 30 personnes animée sur Nantes par Alvin, qui sera notre maître de cérémonie le jour dit). Nous remercions d’ailleurs les participants . . . → Lire la suite: Scrum Day : J – 7 !]]>

La date fatidique approchant, nous sommes en train de préparer activement nos interventions :

– rodage de l’Agile Game “Lego4Scrum” dans nos agences de Paris/ Levallois et Nantes (dont notamment une session à 30 personnes animée sur Nantes par Alvin, qui sera notre maître de cérémonie le jour dit). Nous remercions d’ailleurs les participants à ces sessions, en espérant qu’ils auront passé un moment riche en bonne humeur et en agilité.

– répétition de la présentation “Mise en application de Scrum sur le projet BusinessCenter de PagesJaunes” par  Raphael, Scrum Master du projet.

Rejoignez-nous le 27 Mars au Scrum Day !

A l’occasion de Devoxx France, nous avons décidé de lancer un grand concours de code : attention, ce n’est pas un simple kata de code, l’objectif est de développer une vraie application !

Notre projet . . . → Lire la suite: Bienvenue sur le tatami : Ippon lance un grand concours de code pour Devoxx France !]]> A gagner : 1 Galaxy Tab et deux places de 2 jours pour Devoxx France

Le jeu en quelques phrases

A l’occasion de Devoxx France, nous avons décidé de lancer un grand concours de code : attention, ce n’est pas un simple kata de code, l’objectif est de développer une vraie application !

Notre projet se nomme Tatami. Il s’agit d’un clone de Twitter orienté entreprise : il sera utilisable au sein d’une même entreprise (en l’occurrence Ippon Technologies) afin de permettre à ses salariés d’avoir leur propre plate-forme de microblogging interne et privée.
Le code est disponible ici : https://github.com/ippontech/tatami

Tatami est l’application qui sera utilisée à Devoxx France pour la session “Nouveau look pour une nouvelle vie: Spring, JQuery et HTML5”, le code que vous proposerez dans le cadre du concours pourra donc être montré dans cette session.

Le fonctionnement du concours est simple :

• Vous forkez notre repo Github
• Vous développez de nouvelles fonctionnalités, améliorez le code, etc…
• Au bout de 3 semaines de code, vous pushez votre code et nous sélectionnons le “meilleur” fork

Les technologies actuellement utilisées

Tatami est une application utilisant une base de données NoSQL (Cassandra) et le framework Spring. La couche de présentation est codée en HTML5, utilisant Twitter Bootstrap et JQuery, afin de faire des requêtes REST sur le backend codé avec Spring MVC REST.

L’utilisation de ces technologies est certainement améliorable, en termes de qualité du code proposé comme en termes de performances.

Dans le cadre du concours, vous pouvez bien entendu ajouter de nouvelles technologies (par exemple Lucene pour pouvoir rechercher des Tweets) ou même en remplacer si cela a un sens (amélioration des perfs ou de la qualité du code).

Ce qui a déjà été développé

L’application actuelle permet déjà de poster des tweets, suivre d’autres utilisateurs, lire des tweets, etc…

Par contre de nombreuses fonctionnalités sont manquantes, le code a été écrit de manière relativement rapide, et sans aucun test (méthodologie http://programming-motherfucker.com/, qui n’est peut-être pas idéale….).

Les fonctionnalités manquantes et les bugs

Nous listons les fonctionnalités manquantes et les bugs sur le tracker de Github, avec le label “Concours” :

https://github.com/ippontech/tatami/issues?labels=Concours&sort=created&direction=desc&state=open&page=1

Cette liste est là pour vous donner des idées sur ce que vous pouvez réaliser sur l’application : elle n’est pas à suivre de manière obligatoire, elle est juste là pour vous aider.

Au fur et à mesure du jeu nous ajouterons certainement de nouvelles idées dans cette liste.

Si vous trouvez un bug dans le code actuel, vous pouvez nous envoyer une “pull request” que nous intégrerons alors dans le projet principal :

• Il est donc possible que le code du projet principal évolue légèrement pendant le jeu (ce qui impacte donc tous les concurrents)
• Corriger ce type de bug montre votre fair play dans le jeu, et vous donne donc des “points bonus”

Comment gagner ?

Les gagnants seront élus par Ippon Technologies en fonction des critères suivants :

• Nouvelles fonctionnalités développées
• Design graphique
• Qualité du code
• Performance et scalabilité de l’application
• Bugs corrigés

Afin de nous aider à mieux comprendre votre travail, vous devrez :

• Nous fournir un document décrivant ce que vous avez fait, et pourquoi vous l’avez fait de cette manière
• Si vous avez réalisé des améliorations de performance, un test démontrant ces améliorations sera nécessaire
• Si vous avez ajouté des tests unitaires ou des tests d’intégration, un rapport de couverture de code sera également nécessaire (pour que nous puissions départager deux concurrents ayant fait la même chose)

Le jeu se terminera le Mardi 10 Avril à 8:00, ce qui vous laisse donc 3 semaines !

Quels sont les lots ?

Lot n°1: 1 Galaxy Tab et une place pour 2 jours à Devoxx France
Lot n°2: 1 place pour 2 jours à Devoxx France

Comment s’inscrire ?

Contactez-nous (jdubois chez ippon point fr) pour nous tenir au courant de votre participation, et forkez notre repository Github pour commencer à jouer.

Hajime !

Le programme définitif du Scrum Day 2012 vient d’être annoncé et c’est maintenant officiel : les 2 présentations proposées par Ippon sont retenues !

Nous sommes donc heureux de vous présenter à cette occasion :

Il n’y a pas que le code dans la vie d’un développeur : il y a aussi les données.

Vous avez des données que vous devez filtrer, agréger, transformer ou autre ? Talend va devenir votre ami. Venez découvrir lors de cet Ippevent les possibilités . . . → Lire la suite: Ippevent ETL et Talend : Le Seigneur des Données]]> EDIT : ATTENTION l’IPPEVENT TALEND EST REPORTE AU 22 MARS

Il n’y a pas que le code dans la vie d’un développeur : il y a aussi les données.

Vous avez des données que vous devez filtrer, agréger, transformer ou autre ? Talend va devenir votre ami. Venez découvrir lors de cet Ippevent les possibilités de cet outil et vous familiariser avec les notions liées à l’ETL.

Jérémy Beucler, consultant Ippon, vous présentera le produit, un retour d’expérience et une démonstration de Talend.

Alors si vous voulez voir du concret sur la manipulation de données n’hésitez pas à vous inscrire via notre page Ippevent ou cliquant sur le bouton ci-dessous :

La rapidité de chargement d’une page web dépend essentiellement du temps qu’il faut au navigateur pour en télécharger les données (c.f. la très bonne collection d’articles d’optimisation de yahoo);  La manière la plus efficace et évidente d’optimiser le chargement d’une page est de réduire au maximum les requêtes vers les ressources statiques : css, . . . → Lire la suite: Optimiser ses resources web statiques avec wro4j]]>

La rapidité de chargement d’une page web dépend essentiellement du temps qu’il faut au navigateur pour en télécharger les données (c.f. la très bonne collection d’articles d’optimisation de yahoo);  La manière la plus efficace et évidente d’optimiser le chargement d’une page est de réduire au maximum les requêtes vers les ressources statiques : css, javascript, et images. Pour les images, la solution de la feuille de sprite reste la plus valable pour des raison de compatibilité (pour ce faire, je recommande spritecow) mais il y a une alternative plus “moderne” que j’évoquerai plus tard.  Pour les feuilles de style et les script, la problématique est un peu plus complexe…

l’optimisation du chargement des scripts et des feuilles de style.

Il y a 2 axes principaux d’optimisation. Le premier est la compression des scripts pour en réduire la taille et ainsi en accélérer le chargement, le second, est de limiter le nombre de requêtes en fusionnant les ressources. Un moyen simple de vérifier si vos appels de scripts et de css sont optimisés, est de lancer un diagnostique à l’aide de l’outil de développement de chrome (onglet “audit”, puis “run”), ou encore à l’aide de YSlow.

La compression des javascripts et css se résume en fait à la suppression des espaces et retours à la ligne inutiles ainsi que des commentaires. Pour ce faire, il existe de nombreux scripts connus de compression : YUI compressor, Google Closure, JSMin, Csslint… Mais tous ne se chargent pas de fusionner les fichier ensemble. On peut alors faire en plus appel à des script de merge comme JMerge. Bien évidemment, une fois compressé et fusionné, les .css et .js deviennent illisibles.

La meilleure pratique dans un projet est donc de conserver ces éléments décompressés dans ses sources pour pouvoir développer sereinement, et se charger de la compression lors du build. Et c’est là que le bat blesse. Avec les outils cités précédemment il faut soit compresser son code “manuellement”, soit lancer un script d’exécution lors du build, en shell ou via son outil de build (maven). Rien d’insurmontable, mais pas la panacée en terme de maintenabilité et de stabilité. Si l’on ajoute à cela l’utilisation d’extensions commes Sass ou Coffeescript, cela peut vite devenir un casse tête. C’est là qu’intervient wro4j.

Wro4j : une solution java intégrée.

Présentation

C’est en cherchant une manière facile d’integrer les fusions et compressions de ces ressources à mon build maven que je suis tombé sur le projet java wro4j. Il se charge, soit à l’exécution via un Filter, soit au build via un plugin Maven, de compresser et fusionner vos ressources. En plus d’offrir la possibilité d’utiliser les algorithmes de compression de votre choix (YUI compressor, Google Closure, JSMin, JSlint…), il est très facilement extensible et configurable.

Wro4j opère de la manière suivante : vous définissez des groupes de fichier js et css, et au lieu d’appeler directement les ressources, vous appeler le nom du groupe. A l’exécution le Filter va se charger de constituer vos ressources compressé, et vous renvoyer une seule ressource compacte. Si l’on choisit de faire cela au build, les ressources compressées sont bien évidemment pré générées. Notez que la définition de groupes vous force, à organiser vos resources.

Utilisation

Je peux donc au choix mettre en place wro4j via un filter dans mon web.xml

<filter>
    <filter-name>WebResourceOptimizer</filter-name>
    <filter-class>ro.isdc.wro.http.WroFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>WebResourceOptimizer</filter-name>
    <url-pattern>/wro/*</url-pattern>
</filter-mapping>

Ou en mode build maven dans mon pom.xml

<plugins>
    <plugin>
        <groupId>ro.isdc.wro4j</groupId>
        <artifactId>wro4j-maven-plugin</artifactId>
        <version>${wro4j.version}</version>
        <executions>
                <execution>
                <phase>compile</phase>
                <goals>
                    <goal>run</goal>
                </goals>
             </execution>
        </executions>
        <configuration>
            <targetGroups>all</targetGroups>
            <destinationFolder>${basedir}/src/main/webapp/wro/</destinationFolder>
            <contextFolder>${basedir}/src/main/webapp/</contextFolder>
        </configuration>
    </plugin>
</plugins>

Maintenant admettons que j’utilise un moteur de template pour mon application web et que le template principal contienne les inclusions suivantes :

<!-- début de page -->
<link rel="stylesheet" type="text/css" href="/static/css/style.css" />
<link rel="stylesheet" type="text/css" href="/static/css/global/picto.css" />
<link rel="stylesheet" type="text/css" href="/static/css/global/header.css" />
<link rel="stylesheet" type="text/css" href="/static/css/global/footer.css" />
<link rel="stylesheet" type="text/css" href="/static/css/global/divers.css" />
<!-- fin de page -->
<script type="text/javascript" src="/static/js/jquery/jquery.js"></script>
<script type="text/javascript" src="/static/js/jquery/jquery.ui.js"></script>
<script type="text/javascript" src="/static/js/common.js"></script>
<script type="text/javascript" src="/static/js/mustache.js"></script>
<script type="text/javascript" src="/static/js/iCanHaz.js"></script>

Comme ces inclusions sont à priori communes à toutes les pages du site, l’idéal serait donc de regrouper ces fichiers. Pour cela  je définis le groupe de ressources suivant en xml dans un fichier que je fourni à wro4j (par défaut /WEB-INF/wro.xml) :

<groups xmlns="http://www.isdc.ro/wro">
    <group name="common">
        <css>/static/css/style.css</css>
        <css>/static/css/global/*.css</css>
        <js>/static/js/jquery/jquery.js</js>
        <js>/static/js/jquery/jquery.ui.js</js>
        <js>/static/js/**</js>
    </group>
</groups>

NB : vous remarquerez la possibilité d’utiliser des wildcards.

Wro4j se charge ensuite de compresser et de fusionner les fichiers en fonction des groupes que l’on a défini, au build, ou à la volée si l’on utilise le filter. Pour appeler les ressources du groupe “common” définit précédemment dans nos pages web :

<link rel="stylesheet" type="text/css" href="/wro/common.css" />
<script type="text/javascript" src="/wro/common.js"></script>

Mode opératoire

La classe centrale de wro4j est WroManager. Elle offre un ensemble de possibilités de personnalisation simple. Le WroManager opère de la manière suivante : (cf : http://wro4j.googlecode.com/svn/wiki/img/wro4j-process.png)

1) Construire le modèle de données

Le WroModel contient les informations de regroupement des fichiers, et va permettre leur fusion par la suite. Il est construit par une WroModelFactory, capable de lire ces information sous forme :

• de xml (cf l’exemple précédent)
• de groovy
• de json

Par défaut, la SmartWroModelFactory est appelée. Elle va essayer de trouver les informations sous ces 3 formats successivement. Il est également très simple de faire sa propre WroModelFactory.

2) Localisation des ressources à traiter à l’aide d’une classe Locator

3) Pre-traitement des ressources.

Par exemple compilation de coffeescript, ou Sass, mais surtout réécriture des urls des images dans le css, et la minification des ressources.

4) Fusion des ressources.

5) Post-traitement des ressources.

Les classes et interfaces utilisées pour la construction du modèle et la localisation des ressources sont facilement extensible/implémentable, comme nous le verrons dans l’exemple suivant. Pour les étapes de pre et post-processing, wro4j offre une configuration par défaut, mais il existe de nombreux processors disponibles. A noter que ces processors sont également utilisables de manière autonome.

Un exemple de “customisation”

A titre d’exemple, je vais vous faire un retour d’expérience :  j’ai souhaité faire la déclaration des groupes wro4j directement dans un fichier freemarker – le framework de templating que j’utilisais alors. Le fichier de templating contenant les informations de groupe freemarker, cela lui permet de construire du html appelant soit les ressources décompressées et non fusionnées, soit les ressources assemblées par wro4j (au gré d’un flag dans la configuration du serveur par exemple).

Comme on ne va pas dupliquer ces informations, il faut permettre à wro4j de les lire.

Pour cela, Il m’a suffit d’implémenter une WroModelFactory (cf étape 1), qui construit le modèle de groupes wro4j (WroModel) à partir des données stockées dans le fichier freemarker :

public class CustomWroModelFactory implements WroModelFactory {
    private static final String PACK_EXT = ".pack";
    /**
     * method create, appelée par le framework wro4j
     * renvoie un model wro.
     */
    @Override
    public WroModel create() {
        ParsedResourceContainer container = parseModel();
        WroModel model = new WroModel();
        for (CustomWroModelFactory.ParsedResourcesGroups rgroup : container.resources_groups) {
             Group group = new Group(rgroup.name + PACK_EXT);
             for (String cssFilePath : rgroup.resources.css) {
                  group.addResource(Resource.create(cssFilePath,ResourceType.CSS));
             }
             for (String jsFilePath : rgroup.resources.js) {
                  group.addResource(Resource.create(jsFilePath,ResourceType.JS));
             }
             model.addGroup(group);
        }
        return model;
    }
    /**
    * va parser la variable resources dans mon fichier freemarker
    * à l’aide de (l’indispensable) Gson http://code.google.com/p/google-gson/
    */
    public ParsedResourceContainer parseModel() {
         //
    }
    /**
     *Un bean pour stocker les données parsée par Gson
    */
    private class ParsedResourceContainer{
         //
    }
}

NB : Comme les variables freemarker on un format proche du Json j’ai utilisé Gson pour parser.

Puis il suffit de faire un CustomWroManager factory qui va appeller CustomWroModelFactory :

/**
* Factory pour un wro manager (objet 'central' de wro4j)
* surchargeant la méthode newModelFactory afin de renvoyer
* la CustomWroModelFactory
*/
public class CustomWroManagerFactory extends DefaultStandaloneContextAwareManagerFactory {
    @Override
    protected WroModelFactory newModelFactory() {
        return new CustomWroModelFactory();
    }
}

Il ne reste qu’a configurer le build maven en lui spécifiant la WroManagerFactory à utiliser :

<plugin>
    <groupId>ro.isdc.wro4j</groupId>
    <artifactId>wro4j-maven-plugin</artifactId>
    <version>1.4.1</version>
    <executions>
        <execution>
            <phase>compile</phase>
            <goals>
                <goal>run</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
          <wroManagerFactory>webcore.buildhelper.CustomWroManagerFactory</wroManagerFactory>
          <minimize>true</minimize>
          <destinationFolder>${project.build.directory}/${project.build.finalName}/wro/</destinationFolder>
          <contextFolder>${basedir}/src/main/webapp/</contextFolder>
    </configuration>
</plugin>

…pour que les fichiers compressés/fusionnés soient créés lors du build, à partir des données de mon fichier freemarker.

Conclusion

Il existe des solutions similaires à wro4j, telles que Jawr (dont wro4j s’est surement inspiré), mais j’ai choisi de l’utiliser car :

• Il est très bien documenté.
• L’activité du groupe google-code wro4j est importante.
• J’avais un bug – non bloquant – sur un cas particulier de réécriture des urls des images css, je l’ai signalé au groupe google de wro4j et il a été corrigé dans la release suivante.
• Les releases sont fréquentes, et ajoute de nouvelles fonctionalités.
• Il gère un nombre varié d’algorithmes de compression et de traitement des ressources (je pense notamment à à des “langages” comme CoffeScript ou Sass).

Enfin, je mentionnais en introduction qu’il existe une autre manière d’optimiser le chargement des images que les feuilles de sprite : il s’agit des data URIs, un type d’uri de plus en plus utilisé qui plutôt que de donner une référence à une donnée via une url, donne directement cette donnée encodée en Base64. Et bien wro4j gère également la conversion d’images en base64 dans vos css.

Si vous avez affaire à des problématiques d’optimisation des ressources statiques, je vous recommande donc de jeter un oeil sur wro4j. J’ai été vraiment impressionné par son adaptabilité, son extensibilité et sa simplicité d’utilisation.

(EDIT) : Le JUG a récupéré une nouvelle salle donc les inscriptions sont ré-ouvertes. Rendez vous sur le site du Ch’ti Jug pour vous inscrire.

Une nouvelle fois, votre humble serviteur ira présenter la conférence “Stateful is Beautiful” dans l’un des nombreux Jugs français. Cette fois, c’est à Lille, au Cht’i, Jug que j’aurai . . . → Lire la suite: Speaker Ippon à la soirée Web Stateless vs Stateful du Chti Jug le 23 février 2012]]>

(EDIT) : Le JUG a récupéré une nouvelle salle donc les inscriptions sont ré-ouvertes. Rendez vous sur le site du Ch’ti Jug pour vous inscrire.

Une nouvelle fois, votre humble serviteur ira présenter la conférence “Stateful is Beautiful” dans l’un des nombreux Jugs français. Cette fois, c’est à Lille, au Cht’i, Jug que j’aurai le plaisir d’officier le 23 février prochain.

Comme la fois précédente (au Lyon Jug), je serai opposé à un défenseur des architectures Stateless en la personne de Thomas Recloux (@thomasrecloux), régional de l’étape qui viendra parler des bienfaits de Play! Framework. Tous les détails de cette soirée Architecture Web Stateless vs Stateful sur le site du Chti Jug.

Les places pour cette session sont parties en quelques minutes (c’est dire l’engouement autour du Stateful ), mais il est toujours possible (et chaudement recommandé) de s’inscrire pour permettre aux organisateurs d’obtenir une salle plus grande. N’hésitez donc pas à vous mettre en liste d’attente pour débloquer cette salle.

Venez nombreux : le débat sur la question est toujours enrichissant et peux même être surprenant.

Le JDK propose deux . . . → Lire la suite: Monitorer une JVM en local]]> Le JDK de Sun/Oracle propose plusieurs outils et APIs pour monitorer une jvm locale et ceci, depuis le JDK 6, sans avoir besoin de configurer cette jvm de manière particulière (enfin, ca c’est dans les cas simples nous verrons qu’il faut parfois ajouter une petite option)

Les outils du JDK

Le JDK propose deux utilitaires avec une interface graphique : JConsole et JVisualVM. Le premier permettant principalement d’accéder facilement aux MBeans JMX exposés par la JVM. Le deuxième étant beaucoup plus complet, en particulier si vous utilisez les plugins en téléchargement optionnel.

Il propose aussi des outils en ligne de commande :

• jps (liste des process java)
• jstat (statistique sur le jvm en particulier sur l’état de la mémoire)
• jstack (pour demander un thread dump), jmap (pour demander un heap dump)

Tous ces outils sont présents dans le répertoire bin du JDK.

Ces outils sont soumis à quelques restrictions :

• certaines sont liées à des questions de sécurité. En particulier, ils ne sont souvent utilisables que par l’utilisateur qui exécute les jvms à monitorer
• d’autres restrictions sont moins évidentes ; elles sont en partie décrites ici : http://visualvm.java.net/troubleshooting.html

Sous windows, je rencontre actuellement des problèmes lorsque je me connecte à un serveur à distance (via Remote Desktop) : généralement, il faut toujours au moins que je me connecte en mode admin (mstsc.exe /admin (ou /console dans les anciennes versions) ) pour que les outils de monitoring puisse fonctionner. Mais cela ne suffit pas toujours …

Accès programmatiques

Ces outils sont très intéressants, mais il est parfois nécessaire d’accéder à des métriques particulières d’une jvm ou de l’application que la jvm héberge. Ou ils peuvent tout simplement ne pas fonctionner dans certains cas particuliers.

Dans la suite de ce post, je vais me focaliser sur les différentes façons d’accéder au serveur jmx des jvms en local sans avoir à configurer l’accès distant : qui peut se révéler complexe si l’on veut que cet accès reste sécurisé ( tout est dédrit ici : http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html )

L’API Attach

L’utilisation de l’API Attach pour se connecter à un serveur jmx en local est décrit sur la même page web que l’accès distant :

http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html#gdhkz

Cette api permet essentiellement :

• de découvrir les jvms disponibles
• récupérer quelques  informations sur ces jvms (propriétés système et propriétés des agents chargés)
• charger un agent à l’intérieur de la JVM cible

Cette dernière fonctionnalité permet en particulier de charger l’agent JMX si il n’est pas déjà lancé. On peut lancer l’agent jmx au démarrage de la jvm via l’option -Dcom.sun.management.jmxremote. A partir du JDK 6, c’est grâce à l’API Attach, que cette option n’est souvent plus nécessaire : l’agent peut être chargé à la demande comme montré dans l’exemple ci-dessous.

(ce programme nécessite que le jar tools.jar présent dans le répertoire lib du JDK soit dans le classpath)

package jmx;

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.File;
import java.lang.management.ManagementFactory;
import java.lang.management.RuntimeMXBean;
import java.util.List;

import javax.management.MBeanServerConnection;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;

import com.sun.tools.attach.VirtualMachine;
import com.sun.tools.attach.VirtualMachineDescriptor;

public class JmxAttachAPI {
	public static void main(String[] args) throws Exception {
		new JmxAttachAPI().dotIt();
	}

	static final String CONNECTOR_ADDRESS = "com.sun.management.jmxremote.localConnectorAddress";

	private void dotIt() throws Exception {

		System.out.println("Available local vms : ");
		List vmdList = VirtualMachine.list();
		for(VirtualMachineDescriptor vmd : vmdList) {
			System.out.printf("%s : %s%n", vmd.id() , vmd.displayName());
		}

		// Choose one vm :
		System.out.println();
        BufferedReader stdin = new BufferedReader(new InputStreamReader(System.in));
        String pid = "";
        while(pid.length() == 0)  {
            System.out.println("vm id ? ");
            pid = stdin.readLine();
        }

        System.out.println();
        System.out.printf("Connecting to jvm : %s%n",pid);
		VirtualMachine vm = VirtualMachine.attach(pid);
		String connectorAddress = null;
		try {
			// get the connector address
			connectorAddress = vm.getAgentProperties().getProperty(CONNECTOR_ADDRESS);

			// no connector address, so we start the JMX agent
			if (connectorAddress == null) {
			   System.out.println("Agent not Started, loading it ...");
			   String agent = vm.getSystemProperties().getProperty("java.home") +
			       File.separator + "lib" + File.separator + "management-agent.jar";
			   vm.loadAgent(agent);

			   // agent is started, get the connector address
			   connectorAddress =
			       vm.getAgentProperties().getProperty(CONNECTOR_ADDRESS);
			} else {
				System.out.println("JMX Agent already started !");
			}
		} finally {
			vm.detach();
		}

		System.out.println();
		System.out.printf("Connecting to jmx server with connectorAddress : %s%n",connectorAddress);

		// establish connection to connector server
		JMXServiceURL url = new JMXServiceURL(connectorAddress);
		JMXConnector connector = JMXConnectorFactory.connect(url);

		MBeanServerConnection con = connector.getMBeanServerConnection();

        RuntimeMXBean runtime = ManagementFactory.newPlatformMXBeanProxy(
               con, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
        System.out.printf("Extracted classpath : %s%n",runtime.getClassPath());

	}
}

Et voici un exemple de son exécution :

Available local vms :
8372 : org.apache.catalina.startup.Bootstrap start
2108 : jmx.JmxAttachAPI

vm id ?
8372

Connecting to jvm : 8372
Agent not Started, loading it ...
Connecting to jmx server with connectorAddress : service:jmx:rmi://127.0.0.1/stub/rO0ABXNyAC5qYXZheC5tYW5hZ2VtZW50LnJlbW90ZS5ybWkuUk1JU2VydmVySW1wbF9TdHViAAAAAAAAAAICAAB4cgAaamF2YS5ybWkuc2VydmVyLlJlbW90ZVN0dWLp/tzJi+FlGgIAAHhyABxqYXZhLnJtaS5zZXJ2ZXIuUmVtb3RlT2JqZWN002G0kQxhMx4DAAB4cHc6AAtVbmljYXN0UmVmMgAADzE2OS4yNTQuMTQxLjIwNAAA1Qkf/eH4sQVkBOeL7SsAAAE1TnnPy4ABAHg=

Extracted classpath : C:\products\apache-tomcat-6.0.32\bin\bootstrap.jar

Après avoir listé les jvms disponibles, ce programme s’attache à la jvm sélectionné et regarde si l’agent jmx est déjà chargé (en cherchant la propriété com.sun.management.jmxremote.localConnectorAddress)

Si il ne la trouve pas, il demande à la jvm de charger cet agent (l’agent est dans le jar management-agent.jar présent dans le répertoire jre/lib/ de la jvm cible)

Notez que la JConsole fait exactement la même chose : elle l’indique d’ailleurs dans la fenêtre de connexion en affichant “Note : The management agent will be enabled on this process” sous la liste des process disponibles lorsque le process sélectionné n’a pas encore l’agent JMX chargé

Une fois l’adresse jmx locale récupérée, l’API Attach a terminé son travail. L’api JMX prend ensuite le relai.

Ici on se contente d’extraire le classpath de la JVM cible. Mais l’ensemble des MBeans JMX de la JVM sont maintenant accessibles : que ce soit les MBeans de la JVM ou les MBeans que l’application aurait exposé dans le serveur JMX de la JVM

L’API MonitoredHost

Dans certains cas, l’API Attach ne fonctionne pas … (lorsque la JVM est exécutée par un service windows en particulier ; du moins dans l’environnement où je travaille actuellement)

JConsole utilise une 2ème API pour lister les jvms et extraire des infos : sun.jvmstat.monitor.MonitoredHost. Il utilise aussi une autre api bas niveau sun.management.ConnectorAddressLink : pour récupérer l’adresse JMX local

La limitation principale de cette api est qu’elle n’est pas capable d’activer l’agent JMX s’il ne l’est pas déjà. Il faut donc l’avoir activer explicitement via l’option -Dcom.sun.management.jmxremote (même avec un jdk 6 ou plus)

Sous réserve que l’agent jmx soit activé, on peut donc accéder au serveur JMX de cette façon :

(ce programme, très fortement inspiré du code source de la JConsole, nécessite aussi que le jar tools.jar soit dans le classpath)

package jmx;
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.lang.management.ManagementFactory;
import java.lang.management.RuntimeMXBean;
import java.util.HashMap;
import java.util.Map;
import java.util.Set;

import javax.management.MBeanServerConnection;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;

import sun.jvmstat.monitor.HostIdentifier;
import sun.jvmstat.monitor.MonitoredHost;
import sun.jvmstat.monitor.MonitoredVm;
import sun.jvmstat.monitor.MonitoredVmUtil;
import sun.jvmstat.monitor.VmIdentifier;
import sun.management.ConnectorAddressLink;

public class JmxMonitoredHost {

    public static void main(String[] args) throws Exception {
        new JmxMonitoredHost().doIt();
    }

    private void doIt() throws Exception {
        MonitoredHost localMonitoredHost = MonitoredHost.getMonitoredHost(new HostIdentifier((String)null));
        Set activeVms = localMonitoredHost.activeVms();

        Map pidToAddress = new HashMap();

        System.out.println("Available local vms : ");
        for(Integer vmId : activeVms) {
            String pid = vmId.toString();
            try {
              MonitoredVm localMonitoredVm = localMonitoredHost.getMonitoredVm(new VmIdentifier(pid));

              String commandLine = MonitoredVmUtil.commandLine(localMonitoredVm);
              boolean attachable = MonitoredVmUtil.isAttachable(localMonitoredVm);
              String connectorAddress = ConnectorAddressLink.importFrom(vmId.intValue());

              System.out.printf("%5s %30s %4s%n",pid,commandLine,attachable);
              pidToAddress.put(pid,connectorAddress);

              localMonitoredVm.detach();
            } catch (Exception e) {
                e.printStackTrace();
            }
        }

		// Choose one vm :
        System.out.println();
        BufferedReader stdin = new BufferedReader(new InputStreamReader(System.in));
        String pid = "";
        while(pid.length() == 0)  {
            System.out.println("vm id ? ");
            pid = stdin.readLine();
        }

        // get the connector address
        String connectorAddress = pidToAddress.get(pid);
		System.out.println();
		System.out.printf("Connecting to jmx server with connectorAddress : %s%n",connectorAddress);

        // establish connection to connector server
        JMXServiceURL url = new JMXServiceURL(connectorAddress);
        JMXConnector connector = JMXConnectorFactory.connect(url);

        MBeanServerConnection con = connector.getMBeanServerConnection();

        RuntimeMXBean runtime = ManagementFactory.newPlatformMXBeanProxy(
        		con, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
        System.out.printf("Extracted classpath : %s%n",runtime.getClassPath());

    }

}

L’API LocalVirtualMachine de la JConsole

La JConsole a implémenté sa propre api de découverte au dessus des apis décrites ci-dessus : sun.tools.jconsole.LocalVirtualMachine ( On pourra trouvé son code source ici par exemple : http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/tools/jconsole/LocalVirtualMachine.java.html)

Plutôt que d’utiliser ces deux Apis directement, il est donc plus simple d’utiliser LocalVirtualMachine

Cela nous donne ceci :

( ce programme nécessite tools.jar ET jconsole.jar dans la classpath pour fonctionner ) :

package jmx;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.lang.management.ManagementFactory;
import java.lang.management.RuntimeMXBean;
import java.util.Map;

import javax.management.MBeanServerConnection;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;

import sun.tools.jconsole.LocalVirtualMachine;

public class JmxJConsole {

	public static void main(String[] args) throws Exception {
		new JmxJConsole().doIt();
	}

	private void doIt() throws Exception {

		Map allVirtualMachines = LocalVirtualMachine.getAllVirtualMachines();

		System.out.println("Available local vms : ");
		for(Integer vmId : allVirtualMachines.keySet()) {
			LocalVirtualMachine vm = allVirtualMachines.get(vmId);
			System.out.printf("%10s %50s %s%n",vmId,vm.displayName(),vm.isAttachable());
		}

		// Choose one vm :
        System.out.println();
        BufferedReader stdin = new BufferedReader(new InputStreamReader(System.in));
        String pid = "";
        while(pid.length() == 0)  {
            System.out.println("vm id ? ");
            pid = stdin.readLine();
        }

        // get the connector address
        LocalVirtualMachine vm = allVirtualMachines.get(new Integer(pid));
        // load jmx agent if necessary/possible :
        vm.startManagementAgent();
        String connectorAddress = vm.connectorAddress();

        System.out.println();
		System.out.printf("Connecting to jmx server with connectorAddress : %s%n",connectorAddress);

        // establish connection to connector server
        JMXServiceURL url = new JMXServiceURL(connectorAddress);
        JMXConnector connector = JMXConnectorFactory.connect(url);

        MBeanServerConnection con = connector.getMBeanServerConnection();

        RuntimeMXBean runtime = ManagementFactory.newPlatformMXBeanProxy(
        		con, ManagementFactory.RUNTIME_MXBEAN_NAME, RuntimeMXBean.class);
        System.out.printf("Extracted classpath : %s%n",runtime.getClassPath());

	}
}

Conclusion

Avec ce dernier code, vous devriez être paré pour vous connecter en local aussi bien que JConsole et extraire vos propres métriques ou lancer des opérations de diagnostique (au hasard : lancer un heap dump) via les Apis JMX de la jvm

Toutefois même la JConsole n’arrive pas tout le temps à se connecter ou à voir une jvm local.

En cas de soucis, voici au moins trois pré-requis qui m’ont été nécessaire récemment :

• exécuter JConsole (ou votre code custom) avec le même utilisateur que la JVM cible
• si vous vous connecté en remote desktop sur un serveur Windows : utiliser le mode admin : mstsc.exe /admin
• activer explicitement l’agent jmx sur votre jvm cible (via -Dcom.sun.management.jmxremote)

L’objectif d’Hibernate OGM est d’explorer comment réutiliser Java Persistence et son API familière pour persister les entités dans une base NoSQL.

Il offre une implémentation JPA (manipulation d’objet et requêtes JP-QL) tout . . . → Lire la suite: Ippevent Hibernate OGM par Emmanuel Bernard le 9 février]]> PaaS, Cloud. Mais le vrai challenge c’est comment et où stocker vos données. Dans du NoSQL ? Peut-on utiliser une API familière ?

L’objectif d’Hibernate OGM est d’explorer comment réutiliser Java Persistence et son API familière pour persister les entités dans une base NoSQL.

Il offre une implémentation JPA (manipulation d’objet et requêtes JP-QL) tout en stockant et requêtant les données d’une grille clé/valeur (et d’autres approches NoSQL dans un second temps). Cela inclus notamment de supporter des applications JPA existantes.

Dans cette présentation, nous allons:

• faire un survol du monde (NoSQL) et voir en quoi une API comme JPA apporte un intérêt
• voir comment Hibernate OGM stocke les entités et les associations dans la base clé/valeur et explorer les compromis fait
• voir comment les requêtes JP-QL sont implémentés au dessus d’une technologie qui ne supporte pas la notion de requête (clé/valeur) et quel niveau peut être couvert

Attention: contient des démos qui tournent !

Pour vous inscrire, il vous suffit de cliquer sur le bouton ci-dessous (si vous désirez plus d’information vous pouvez aussi vous inscrire depuis notre page Ippevent :

Une critique fréquente faite à l’encontre Java EE est la difficulté à tester ses composants comme les EJB ou les Beans CDI. L’outil de test JBoss Arquillian apporte une réponse puissante à ce problème . . . → Lire la suite: Ippevent Arquillian le 19 janvier]]> Pour débuter cette nouvelle année 2012 (que je vous souhaite bonne et heureuse), nous démarrons avec un outil novateur : Arquillian.

Une critique fréquente faite à l’encontre Java EE est la difficulté à tester ses composants comme les EJB ou les Beans CDI. L’outil de test JBoss Arquillian apporte une réponse puissante à ce problème et à bien d’autres concernant les tests d’intégration.

Alexis Hassler, spécialiste Java EE 6 et membre éminent du Lyon Jug nous présentera lors de cet Ippevent cette solution de test nouvelle génération qui vous aidera que vous utilisez Java EE ou Spring.

Pour vous inscrire, il vous suffit de cliquer sur le bouton ci-dessous ou de vous rendre sur notre page Ippevent.

Il y a quelques semaines nous vous annoncions notre soutien en tant que sponsor de DevoXX France les 18, 19 et 20 avril 2012 à Paris.

Alors être sponsor c’est sympa :

http://blog.ippon.fr/2011/11/30/jeu-ippon-recrute-deuxieme-edition/

Un excellent retour sur ce jeu a été fait par Sébastien Prunier, et nous allons d’ailleurs nous baser sur sa solution pour la suite de ce billet. En effet, la dernière partie du jeu consistait . . . → Lire la suite: Attaque brute force, Java et parallélisme]]> Ippon a lancé il y a un peu plus d’une semaine un jeu qui a eu un beau succès:

http://blog.ippon.fr/2011/11/30/jeu-ippon-recrute-deuxieme-edition/

Un excellent retour sur ce jeu a été fait par Sébastien Prunier, et nous allons d’ailleurs nous baser sur sa solution pour la suite de ce billet. En effet, la dernière partie du jeu consistait à faire un algorithme de “brute force” afin de déchiffrer un mot de passe. Certaines personnes ont cru, à tort, qu’il s’agissait juste de faire une boucle “while” et de tester tous les cas possibles: cela rendait le déchiffrable impossible, à moins d’avoir beaucoup de temps disponible… Bien entendu il y avait une astuce, que pas mal de monde (dont Sébastien) a trouvé: étant donné qu’il s’agissait de trouver les lettres d’un pseudo-Sudoku, il n’y avait que 9 lettres possibles, qui ne répétaient pas, soit 9! possibilités (9! = 9*8*7*6*5*4*3*2*1 = 362 880 possibilités).

Le code de Sébastien permet ainsi de trouver la bonne combinaison en 80 secondes (sur mon MacBook):

https://github.com/sebprunier/IpponRecrute/blob/master/src/main/java/fr/ippon/rh/support/ForceBrute.java

Cependant, on peut faire plus performant: pour être exact, “probablement plus performant”, car tout dépend de vos données (plus le résultat se trouve “loin” dans notre jeu de test, plus la parallélisation va nous faire gagner du temps).

Nous allons pour cela voir plusieurs méthodes différentes: Node.js, Scala, Java “pur” et Spring.

Méthode n°1: utilisation de Node.js

Plusieurs personnes ont remonté qu’en utilisant Node.js, on pourrait certainement faire mieux. Voilà un bon exemple du “hype oriented computing”, que l’on m’a déjà sorti plusieurs fois lors du challenge USI 2011: node.js n’est volontairement pas multi-threadé, pour éviter de faire du context switching et éviter d’empiler des threads (typiquement une thread par utilisateur, comme c’est le cas dans beaucoup de nos “vieux” serveurs d’applications Java qui ne font pas de NIO). Cela permet d’avoir des applications très réactives, et qui supportent beaucoup d’utilisateurs, à partir du moment où ces applications “attendent” la majeure partie du temps. C’est un cas classique d’utilisation des serveurs d’applications: ils passent une grande partie de leur temps à attendre les données provenant d’une base de données. Node.js est donc particulièrement adapté à des sites Web utilisant une base de données complexe, mais est par contre peu adapté à des sites Web faisant beaucoup de calcul en local: un excellent exemple est donné en début du post maintenant célèbre “Node.js is Cancer“.

Ajoutons que sur nos machines modernes, l’histoire va plutôt dans le sens inverse de Node.js: nous avons de plus en plus de coeurs, chacun étant généralement moins puissant que la génération précédente.

Méthode n°2: utilisation de Scala

Scala 2.9 permet d’avoir des collections utilisant automatiquement les différents coeurs de votre système: c’est en quelque sorte l’inverse de l’approche de Node.js! Vous pouvez donc itérer sur une collection, et les traitements sur cette collection utilisent alors automatiquement plusieurs threads, répartissant ainsi les traitements sur l’ensemble des coeurs du système.

(1 to 1000000).toArray.par.map(_*2)

Le .par dans le code précédent dit à Scala d’utiliser les collections “parallèles”. Dans la pratique, ce code a cependant beaucoup de problèmes:

• Il va utiliser le framework Fork/Join de Java 7: donc si vous êtes sour Mac OS X, comme moi, cela ne va simplement fonctionner que sur une seule thread.
• <troll> Il est écrit en Scala, et donc personne ne le comprend </troll>

Méthode n°3: Java pur

package fr.ippon.rh.service;

import org.jasypt.util.text.BasicTextEncryptor;

import java.util.*;

/**
 * Resolution de l'etape 3 par force brute.
 *
 * @author Sébastien Prunier
 * @author Julien Dubois
 */
public class MultiForceBrute {

    // Texte a decrypter
    private static final String etape4Texte = "5oi/MCVWOrk2V8bI2LY4XM4gKf/hqRnz6/d0HftJYadMv7xkIjUsTfvXyyf0kJ/D1Or0QMicOUf7YIAkAMWkbNJpLA5cgOHZvGZVC1LBGdpe0n3zY5VfyYjUIFu/0VNyLVMOAu4BaC3ncdPkh5Q0r+IQeTV+IqOOBlsozTfxeLYBJhxIUdSaXIVubo7RSPOn1Y0aLrTEZhlPkJFJhQohhOr5d0/zqre7HnFdc/9vSC3qda6VKwxd+yAhl762kOGReE4YbeMX/1wg175ruUaT4tgVYaOLXIRg0fqZYIwu37KUrOvtUD+inZSYwMpUrNSeV9Wshwoi6kBXkriEoc2Qg58b6WVfNTzGMFsRp/D4TGMx04hGg2WTT4lRPebqGl5cPm6qSeb7WET3xbJ4LUCvOgX0cDr22inxlGUgkbF7m8ApZw2kOverBgnhW+dE3amE+bP1Ac1ky4sSY0Sjeec2n4QI6hX9mwl7GBc9Ep8uF7t+XdZFmuml4/bFgxtDOpi8zQ6NYXe2/UT5S6i/hPPHHRa6OGL2ZAswBtAkcsYiw564hshKvzVOMtP05Zu19C1zY+84kmpsGbxxknSI61owCNOvF1tJitww4EmkLsIhgveV+RcmTQOiwONJET7Q9qK4RFpFuz+hu1Kel0QsMPZMlvhSsSTj+lmLHzG9nC5s4RcvLR1JeL27MvcfO0CxZx9XSYazu+LqVK2qlv+NXftT9JFx19hVIvAI/T4oM9xf3wYrLozs1GDRrPju2yVXZb91vn4TdWWIoXI8yGQ5AaHYVLNu5LVez/Q4sH/DRjjMHLGTsYpXNm/xRrwf10Aw78dO58dvUy+ClP6//0wq+9+tw4knCtZwPK6Ov1gqvCzUlp3voDO+J/7/9+OoA4OkdJv8Nsu02lWZ6/mDsrr49U8D8mJgmqze4jVLbXg61HCuzSCOhnHPtMmyfykDSFHXvSGCiuyGoWN5ObIAo/k9XxYlZNrGpwYq3aTwaKJwG1vTtLzHop0bfQ50+cz18LqynMB2t+Y5AQ9IGAvJX6nWrO/C8GBD/bE/lZT+i1XYhYJ0JB0zoadQK+AkyNNiwUe9Dv31e614zgVTGlJ/JvSQGBCAcK+wYNDK1fVY2EEWyQhlQ3BYdwcqF4myOI7wtZsPscwO1Kc8TwlPGypQ/6JG4Q5AUeXmzrXi67boN0tB4YUyG5cQk7Ehe3gaHI7rF5IGYT1id7agEcxphjRWMTo9fT9zIb2tsA9SBw+tici5y2E7xHbnEcMjF4xuGWjEy7sr8+PktLQldvcyAo0jkwlN8G6PyL7R1HcWITr8W9T3Qr4Yq3vazV16pDf7tofDEdoI9/9jt8wchTd1gCh/fnZk88TblEJqGnbrsPL+V2S+/YaLv7A7nZ1Bjy9WiQYiGnO1tgqMMbwt470eb1mIKyOcarrGcAATiEq8DxE1H8xeEpy23BtdTHJwT5COhCY+WbEWcYvCh6tBVs2PPvGSCJvClW2sR0n16kdtQiYS7uOiyOANoVy5ZygJ4jITiik3Lcfm3rE1DLaOM44DjRy1W5YTq7dXYKBsXcdoc+JmZ+7naVcBQ2q2XlZ/t2EvN9k1rVW4x7o7V7YsE2bbPqyvAxt0w1NsgVUaAsff361KxJgD7JXQXdpEyD+6KE1N+SmUOOUG22OxOZbsHy/+WPTKboQ5AMFG8pgR61TfAA6YqPakrGMKYGkpe0T+1t82Zo1t3Q+z2WxSLdRX5bslJjfuZSqqCpao40BbIEEFYAlmkTgDuKIaP4dA9o+b0M+lPjIM/mwWjxDdOraR3w0ncnyrUigGGisYsT5KHh89VHcyv94gJdMeT+5LC/7plTAd5HhMfp1Gq8f/6L1NWuhgyD/ne8VhNOuThkf53e5QzEuhUJqc8P/A68U/TG83SFgVRiPG2h06bEGC6yztEYlT/LPBQJkcB0I2Yg4BbcJRXTc6mZT54Fato3zRPYlqXdniQsxTR8w6WgVbRF93bn99lrJc9lLnqn9F8cFTG5QKp9u45yExo2Hy/0jmcpHyhaLlJP/ECuEeQK7M5H2Ro3rG2wwcAiuK0JV0meM6Isij2z4ldl2agyR2TKNgVcCynrScqFpzkEgwmPY6XuU/+qN89fgsRJ+8uuL0V1ah4zl70ymEzMYX48bI8icCIP4BFVp+mBymy2AUo7ln8zfxW4DKlZgVeyBsluDUqjn111m4oq/JkbzwlW3/D+KU9Yb52KwcHmbnpO8TcKXprhk2iJ04ak3IWY1u+pNU8WZRz3+jQWoPpIQtA8DQQdIYXrKwgXVerMsp2g4Tj0Irf5RnpcbjzXNM2A2mBo6ak/dp1I0tFK3Ue5HfSeBZ6iLBGsKii8VJPCw2AxM/JI74/Cl2BaggiMvpqAhMDyG7EhnaMZfgj+8Kd9P1hTp5nsZWGe3vnwDLLpnDqH4vER7J1uKpm3ig2XGuq3XFo7Fp6naG+B7qlSRF";

    private static long startTime;
    private static boolean stopDecryption;

    /**
     * Programme principal
     */
    public static void main(String args[]) {
        startTime = Calendar.getInstance().getTimeInMillis();

        MultiForceBrute multiForceBrute = new MultiForceBrute();
        multiForceBrute.decrypt();
    }

    private void decrypt() {
        Set passwords = new HashSet();
        permute("", "ABCDEGHIJ", passwords);
        System.out.println("Password size: " + passwords.size());

        int cores = Runtime.getRuntime().availableProcessors();
        System.out.println("Number of cores: " + cores);
        String[] passwordArray = new String[passwords.size()];
        passwordArray = passwords.toArray(passwordArray);
        Collection partitions = new ArrayList();
        int partitionSize = passwordArray.length / cores;
        for (int c = 0; c < cores; c++) {
            String[] partition = Arrays.copyOfRange(passwordArray, c * partitionSize, (c + 1) * partitionSize);
            partitions.add(partition);
        }
        for (String[] partition : partitions) {
            DecryptionThread decryptionThread = new DecryptionThread(partition);
            decryptionThread.start();
        }
    }

    /**
     * Calcul des permutations.
     *
     * @param sStart    chaine de depart.
     * @param sEnd      chaine d'arrivee.
     * @param passwords ensemble des mots de passe.
     */
    private void permute(String sStart, String sEnd, Set passwords) {
        if (sEnd.length()             passwords.add(sStart + sEnd);
        } else {
            for (int i = 0; i < sEnd.length(); i++) {
                String newString = sEnd.substring(0, i) + sEnd.substring(i + 1);
                permute(sStart + sEnd.charAt(i), newString, passwords);
            }
        }
    }

    private class DecryptionThread extends Thread {

        private String[] passwords;

        DecryptionThread(String[] passwords) {
            this.passwords = passwords;
        }

        public void run() {
            for (String password : passwords) {
                if (stopDecryption) {
                    return;
                }
                try {
                    BasicTextEncryptor textEncryptor = new BasicTextEncryptor();
                    textEncryptor.setPassword(password);
                    String decryptedText = textEncryptor.decrypt(etape4Texte);
                    if (decryptedText.contains("ippon")) {
                        System.out.println("Result: " +password);
                        long totalTime = Calendar.getInstance().getTimeInMillis() - startTime;
                        System.out.println("Solved in: " + totalTime + " ms.");
                        stopDecryption = true;
                    }
                } catch (Exception e) {
                    // Bad password !
                }
            }
        }
    }
}

Méthode n°4: Spring

Les trois solutions que nous avons vu, malheureusement, ne sont pas très industrielles: sur un projet en production, personne n’a envie de lancer ainsi des threads qui utilisent tous les coeurs disponibles, sans aucun contrôle.

Pour cela Spring propose une abstraction très intéressante, le TaskExecutor. Nous utilisons ici Spring 3.0 (voici la documentation officielle), sachant qu’il est prévu que Spring 3.1 supporte le framework Fork/Join, comme Scala, mais qu’à l’heure actuelle (Spring 3.1.0.M1), la documentation n’est pas à jour.

Dans sa version la plus simple, ce TaskExecutor permet de définir un pool de threads:

<bean id="taskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
  <property name="corePoolSize" value="5" />
  <property name="maxPoolSize" value="10" />
  <property name="queueCapacity" value="25" />
</bean>

Dans la pratique, ce système permet de centraliser dans un seul endroit la configuration de son pool de Thread, et de pouvoir ainsi l’optimiser:

• On peut bien entendu utiliser le nombre de coeurs disponibles: c’est une variable qui est tout à fait intéressante, car dans un environnement virtualisé le nombre de coeurs disponibles peut être amené à évoluer
• On peut utiliser la configuration Spring pour modifier ces valeurs en fonction des environnements: c’est la notion de profils, qui va elle aussi apparaître avec Spring 3.1, mais qui elle est très bien documentée
• On peut choisir de n’utiliser qu’un seul thread: c’est ce qui arrive en fait très souvent pour les applications Web, car on veut garder la majeure partie des coeurs disponibles pour les utilisateurs. Ainsi, l’ensemble des traitements de fond sont soumis à une seule et même thread, ce qui permet d’avoir une application toujours réactive, quels que soient les traitements lancés. L’intérêt ici est également d’utiliser la même thread pour des traitements différents.
• On peut utiliser le pool de thread du serveur d’applications, et c’est ce que nous allons détailler plus bas.

<bean id="taskExecutor" class="org.springframework.scheduling.commonj.WorkManagerTaskExecutor">
    <property name="workManagerName" value="wm/default"/>
    <property name="resourceRef" value="false"/>
</bean>

Cette configuration permet ainsi au administrateurs de votre serveurs d’applications de modifier le nombre de threads disponibles en fonction des besoins et des capacités disponibles, ce qui est essentiel en cas de charge importante sur le serveur.

https://github.com/ippontech/IpponRecrute

Cependant, certaines personnes ont trouvé ce jeu trop facile, et nous avions alors promis une nouvelle version plus difficile… Voici donc la deuxième édition de ce jeu!

La session du Paris JUG du 8 novembre 2011 était consacrés aux petites librairies Java.

Guillaume Laforge, leader du projet Groovy nous a présenté la librairie PrettyTime développée par Lincoln Baxter III qui travaille chez OcpSoft et RedHat. Celle-ci permet de présenter des dates sous forme . . . → Lire la suite: Paris JUG : Petites librairies Java]]>

G. Laforge expliquant Pretty Time

La session du Paris JUG du 8 novembre 2011 était consacrés aux petites librairies Java.

I. Pretty Time

Guillaume Laforge, leader du projet Groovy nous a présenté la librairie PrettyTime développée par Lincoln Baxter III qui travaille chez OcpSoft et RedHat. Celle-ci permet de présenter des dates sous forme de dates relatives du type : à l’instant, dans 10 minutes, il y a 3 heures. Guillaume l’utilise sur son blog pour afficher la date des posts ce qui permet d’indiquer la date de la façon suivante : Posted on 09 November, 2011 (2 days ago). La librairie est constituée d’un jar n’a pas de dépendance. Elle supporte 18 langues dont le français et l’anglais et est très simple à utiliser.

// on initialise avec une date de reference
PrettyTime t = new PrettyTime(new Date(1000 * 60 * 12), new Locale("fr"));
// on formate une date par rapport a cette date de reference
assertEquals("il y a 12 minutes", t.format(new Date(0)));

on peut utiliser facilement PrettyTime avec Grails ou JSF.

II. GPars

GPars (prononcez Jeepers) est une librairie permettant de s’adapter au multi-processeurs et au multi-coeurs en faisant de la programmation concurrente.

il est difficile de bien utiliser ce  que le JDK propose : threads / synchronize / wait-notify-notifyAll, qui peuvent conduire à

• des dead-locks, des live-locks (in interblocage qui consomme du CPU), des race conditions ou l’épuisement de ressources
• des problèmes de gestion d’accès à la mémoire partagée

Pour éviter ces problèmes, GPars propose d’utiliser l’immuabilité et le passage de messages au travers des paradigmes suivants

• Acteurs
• Fork/Join
• Collections parallèles
• Executors
• Dataflow
• Agent – an thread-safe reference to mutable state
• STM (Software Transactional Memory)
• CSP

un exemple avec les fonctions parallèles pour les collections

@Grab('org.codehaus.gpars:gpars:0.12')
import static groovyx.gpars.GParsPool.withPool

defnums=1..100000
withPool(5){
def squares=nums.collectParallel{it**2}
.grepParallel{it%7==it%5}
.grepParallel{it%3==0}
println squares[0..3]+"..."+squares[-3..-1]

assertsquares[0..3]==[36,144,1089,1296]
}

on utilise un pool de taille nombre de coeurs + 1 afin de maximiser l’utilisation du CPU car souvent on a un thread qui sert à la coordination des autres et qui consomme peu de ressources. GPars a comme dépendance les librairies jsr166y et extra166y. Il dispose d’une API Java et d’une API Groovy.

Selon le problème que l’on a à résoudre on utilisera des outils différents. Cela est bien présenté par le graphe suivant.

les slides de la présentation de Guillaume ici

III. Project Lombok (ou comment cacher la plomberie)

Florent Ramière de la société Jaxio nous a présenté Lombok, “un outil qui sert à enlever la plomberie”. Il s’agit d’un plugin eclipse qui va générer du code technique grâce à des annotations, le source ne sera donc pas pollué par ce code technique qui existera néanmoins dans le bytecode après compilation. En utilisant Lombok on pourra donc clarifier son code et se concentrer sur d’autres parties de son code. On peut bien sûr utiliser les assistants eclipse pour générer un code similaireà celui généré par Lombok.

on dispose notamment des annotations suivantes

@Getter

@Setter

@EqualsAndHashCode

@RequiredArgsConstructor un constructeur avec tous les champs finaux

@Data est un raccourci pour @ToString, @EqualsAndHashCode, @Getter sur tous les champs et @Setter sur tous les champs non-finaux, et @RequiredArgsConstructor! à utiliser pour ses beans.

@Delegate permet de déléguer toutes les méthodes publiques de l’attribut annoté, excepté les méthodes présentes dans java.lang.Object.

@Log et ses variantes @CommonsLog, @Log4j et @Slf4j permet d’instancier une variable statique privée log

@Synchronized permet de générer un bloc synchronize sur une variable privée $lock ou $LOCK (dans le cas d’une méthode statique)

val est un type Lombok permettant d’avoir des variables ‘final’ et de bénéficier de l’inférence de type.On peut ainsi écrire

val map = new HashMap();

la page suivante explique très bien le code généré par Lombok. on peut d’ailleurs si besoin générer ce code en utilisant delombok (pour GWT notamment ou si l’on veut utiliser le code générer sans dépendre de lombok). lombok-pg est un ensemble d’extensions pour lombok.

Lombok peut également être utilisé via ant, maven ou javac.

Au détour de ses démonstrations, florent nous a également conseillé l’outil awaitility qui permet de faire des tests sur du code asynchrone

IV. Apache Commons Configuration

Emmanuel Bourg est membre de la fondation Apache et est commiter sur le projet Apache Commons Configuratio qu’il est venu nous présenter. Il s’agit d’une abstraction de la configuration d’une application qui présente une interface simple de type clé/valeur pour les données. Elle permet de gérer différents formats de données et des transformations dans les types voulus.

On peut gérer un format Properties amélioré

list1=val1,val2,val3
list2=val1
list2=val2
list2=val3
include=chunk.properties

On peut également utiliser des fichiers XML, Property List XML, Ini ou encore une base données.

Plusieurs formats sont prévus : OGDL, YAML, JSON, Registry Windows, Binary Property List. Les contributions sont les bienvenues si vous voulez aider à ajouter le support des nouveaux formats. On peut combiner plusieurs configurations grâce à CompositeConfiguration. On peut également utiliser un descripteur de configuration. Commons Configuration s’intègre très bien avec la librairie d’abstraction de systeme de fichiers Apache Commons VFS.

Sauvegarde automatique

PropertiesConfiguration config = new PropertiesConfiguration("usergui.properties");
config.setAutoSave(true);

Rechargement automatique (on peut également déclencher le rechargement)

PropertiesConfiguration config = new PropertiesConfiguration("usergui.properties");
config.setReloadingStrategy(new FileChangedReloadingStrategy());

V. Guava (N’aime pas les null)

Thierry Leriche-Dessirier (Indépendant) et Etienne Neveu (SFEIR) nous ont fait faire un tour du propriétaire de Guava, la librairie utilitaire de Google autrefois nommée google-collections.

Factory methods

Inférence de type : grâce à des factory statiques on peut écrire

List primeNumbers = newArrayList();
Set colors = newTreeSet();
Map ages = newHashMap();

ce qui n’est plus si intéressant que ca en Java 7 avec la notation diamant.
L’initialisation de collection est également facilitée

List dogs = newArrayList(Dog1, Dog2, Dog3)

Programmation fonctionnelle

On peut filtrer une collection grâce à un prédicat

Iterable maleDogs = Iterables.filter(dogs,
  new Predicate() {
    public boolean apply(Dog dog) {
      return dog.getSex() == MALE;
    }
});

un predicat peut utiliser les prédicats and, in, or, not déjà définis dans la classe Predicates

boolean isMilouInBoth = and(in(dogs), in(superDogs))
            .apply(new Dog("Milou"));

on peut transformer les elements d’une liste en utilisant une Function

List chiens =
Lists.transform(dogs, new Function() {
  public Chien apply(Dog dog) {
    return new Chien(dog.getName());
  }
});

Attention ce sont des vues qui sont retournées. cela peremt d’avoir du lazy-loading mais la conversion sera faite autant de fois que nécessaire.
Iterables.find utilise le même prédicat que pour Iterables filter mais renvoit le premier objet correspondant au predicat ou un objet par défaut si rien ne correspondait au prédicat.

Dog firstMale = Iterables.find(dogs, malePredicate, DEFAULT);

collections immuables

on a des syntaxes plus concises que la syntaxe standard tout en proposant de la copie défensive.

ImmutableSet.of(1, 2, 3, 5, 7);
ImmutableSet.copyOf(favoriteColors)

base.Objects

cette classe propose d’aider à la simplification de l’écriture des méthodes equals(), hashcode() ou toString()

//equals
Objects.equal(name, that.name)
&& Objects.equal(weight, that.weight)
&& sex == that.sex;
// hashcode
Objects.hashCode(name, weight, sex);
//toString
Objects.toStringHelper(this)
   .add("name", name)
   .add("weight", weight)
   .add("sex", sex)
   .toString();

on peut créer facilement un comparateur

public int compareTo(Dog other) {
  return ComparisonChain.start()
    .compare(name, other.name)
    .compare(weight, other.weight)
    .compare(sex, other.sex)
    .result();
}

base.Preconditions

on peut vérifier des paramètres

this.currency = checkNotNull(currency, "currency cannot be null");
checkArgument(amount.signum() >= 0, "must be positive: %s", amount);

base.CharMatcher

il s’agit d’un outil permettant d’exprimer une expression régulière en language naturel. Il permet de remplacer avantageusement StringUtils des Apache Commons.

Collections

on dispose de collections n’existant pas dans le JDK

MultiMap : il s’agit d’une map pouvant avoir plusieurs valeurs pour une même clé

Multimap favoriteColors = HashMultimap.create();

BiMap : il s’agit d’une map pouvant n’ayant pas 2 fois la même valeur

BiMap favoriteColors = HashBiMap.create();

Multiset: il s’agit d’un set pouvant contenir plusieurs fois la même valeur (on peut même connaître le nombre de doublons)

Multiset primeNumbers = HashMultiset.create();

Joiner et Splitter permettent de manipuler les conversions entre chaine de caractères et liste de String.
En utilisant Joiner, on aura une NullPointerException si un des éléments de la liste vaut null mais l’on pourra utiliser skipNulls() ou userForNull(MY_DEFAULT) pour spécifier le comportement lorsque l’on rencontre un null.

List<String> dogs = newArrayList("Milou", "Idefix", "Rintintin");
String names = Joiner.on(", ").join(dogs);

En utilisant Splitter on peut nettoyer le résultat en utilisant trimResults() et omitEmptyStrings()

Iterable<String> superDogs = Splitter.on(",")
   .trimResults()
   .omitEmptyStrings()
   .split("Lassie, , Volt, Milou");

Cache

Memoization

la memoization permet de garder en cache une unique valeur. l’exemple donné était la mise en cache du numéro de version du dernier jdk. On défini via l’utilisation d’un Supplier comment aller chercher la valeur qui nous intéresse. Celle valeur ne sera récupérée que lors du premier appel (lazy loading). Les appels suivant utiliserons le cache.

private Supplier<JdkVersion> versionCache =
  Suppliers.memoize(
    new Supplier<JdkVersion>() {
      public JdkVersion get() {
        return jdkWebService.checkLatestVersion();
      }
    }
);

On peut également préciser une durée de validité du cache avec memoizeWithExpiration()

Key-Value

On peut construire un Cache à plusieurs entrées grâce aux classes CacheBuilder et CacheLoader

private Cache<Long, Film> filmCache = CacheBuilder.newBuilder()
  .maximumSize(2000)
  .expireAfterWrite(30, TimeUnit.MINUTES)
  .build(new CacheLoader<Long, Film>() {
    public Film load(Long filmId) {
      return imdbWebService.loadFilmInfos(filmId);
    }
});

Concurrent

Guava propose d’étendre Future avec la classe ListenableFuture. On peut ainsi associer un listener à un Future.

ListenableFuture<Result> future = ...
future.addListener(new Runnable() {
  public void run() {
    logger.debug("Future is done");
  }
}, executor);

On peut également faire de la programmation asynchrone grâce à FutureCallback. cela permet d’isoler le traitement des exceptions.

Futures.addCallback(future, new FutureCallback<Result>() {
  public void onSuccess(Result result) {
    storeInCache(result);
  }
  public void onFailure(Throwable t) {
    reportError(t);
  }
});

pour utiliser des ListenableFuture on utilise un ListeningExecutorService de la façon suivante.

ListeningExecutorService executor = MoreExecutors.listeningDecorator(executor);

public ListenableFuture<Note> getNote(final Film film) {
  return executor.submit(new Callable<Note>() {
    public Note call() {
      return imdbWebService.getNote(film);
    }
  });
}

En utilisant les méthodes proposées par Futures on peut facilement proposer des méthodes non bloquantes qui renvoient un Future au lieu d’une liste de notes. Cela permet au programme appelant de ne pas bloquer pendant la récupération des notes et d’effectuer d’autres traitements pendant celle-ci.

ListenableFuture
<List<Note>> getNotes(Film film) {
  ListenableFuture<Note> noteImdb = imdbService.getNote(film);
  ListenableFuture<Note> noteAllo = allocineService.getNote(film);
  return Futures.allAsList(noteImdb, noteAllo);
}

Personnellement, ce sont ces deux nouveaux langages qui . . . → Lire la suite: Devoxx: Les deux nouveaux candidats à la succession au langage Java]]> Deux nouveaux langages qui commencent fort

Lors de ce Devoxx 2011, une catégorie de sessions était consacrée aux différents langages de la JVM.
Etaient présents Scala, Phantom, Groovy, JRuby, Clojure et les deux petits nouveaux révélés cette année par leur sponsor : Kotlin (JetBrains) et Ceylon (JBoss/Redhat)

Personnellement, ce sont ces deux nouveaux langages qui m’intéressaient le plus : j’adore la concision de Groovy mais le fait qu’il ne soit pas statiquement typée m’empêche de l’utiliser pour un projet avec un minimum d’envergure. Peut-être que l’un de ces deux langages pourra amener le meilleur de ces deux mondes…

Ces deux langages sont tout nouveaux et toujours en cours d’implémentation. Il n’est pas encore question de les utiliser sur de vrais projets mais nous avons pu voir durant les sessions de Devoxx que chacun avait déjà un compilateur fonctionnel et un IDE pouvant faire la démonstration de complétion, refactoring, debugging, … De quoi commencer à jouer avec a priori.

Caractéristiques

Ces deux langages ont une bonne partie de leurs objectifs en commun :

• langage s’exécutant sur la JVM
• statiquement typé
• compilateur permettant de détecter plus d’erreurs
• avoir une syntaxe plus simple et plus expressive que Java sans être aussi compliqué que Scala
• complètement interopérable avec Java

Il en ressort un grand nombre de caractéristiques communes, comme par exemple :

• inférence de type étendue
• null safety (cf ci-dessous)
• smart cast ou plus généralement des optimisations de syntaxe locale (cf ci-dessous)
• constructeur primaire dans la syntaxe

Par contre, durant la présentation de Ceylon la notion de closure n’a pas du tout été évoquée, il n’est pas clair pour moi si elle sera supporté ou non. Kotlin de son côté les supportera très bien, avec en particulier la possibilité de mettre en oeuvre des “higher-order function”.

Je ne peux pas faire de comparaisons précises sur la base de ces deux présentations, mais au dire de Stéphane Epardaud qui nous a présenté Ceylon avec Emmanuel Bernard : Ceylon et Kotlin ont beaucoup en commun en termes de fonctionnalités. Pour lui, Ceylon se distingue par un système de typage plus abouti ( avec en particulier les union type, intersection type, … ).

Syntaxe

Au niveau de la syntaxe, les deux langages restent assez accessibles aux programmeurs Java, mais s’éloignent tout de même de la syntaxe Java.
Pour citer deux exemples :

• dans Kotlin : le type des paramètres est écrit après son nom, et le type de retour après la définition d’une fonction. Par exemple :

fun main(args : List<String>) : Unit

• dans Ceylon : de nouveaux keywords sont introduits qui remplacent une partie de ceux utilisés en Java ( abstract => formal, @Overide => actual, public/protected remplacé par “shared”, …), du code peut être associé à des properties (pour implémenter le getter ou le setter associé), …

Documentation

Jetbrains a très rapidement mis en place un wiki pour son langage avec pas mal de documentation et des discussions sur les choix effectués et leurs objectifs : http://confluence.jetbrains.net/display/Kotlin/Welcome

Pour Ceylon, c’était plutôt le brouillard en terme de doc, la plupart des références se trouvaient dans des blogs, des présentations, … rendant difficile la création d’un communauté.

Jusqu’à ce matin en fait, où ils nous ont révélé une “One more thing” à la fin de la présention : le tout nouveau site de ceylon : http://www.ceylon-lang.org/ et le github des développements en cours https://github.com/ceylon

Un petit focus sur deux des caractéristiques communes

Null safety

Dans les deux langages : les références ne peuvent pas être null par défaut.
Un type Integer (par exemple) correspondrait à un objet entier non null.
Un type Integer? correspondrait à un objet entier pouvant être null

Pour accéder à un champ ou une méthode sur une référence pouvant être null, il faut absolument utiliser ?. au lieu de simplement . sans quoi le compilateur génère une erreur. Si l’objet est null : l’opérateur ?. aura pour effet d’ignorer la suite de l’expression et de renvoyer simplement null
Exemple en Kotlin :

Int? x = getAnIntegerOrNull()
print (x?.times(2)) // ici, x peut être null : il est nécessaire d'utiliser ?.
                    // pour appeler la méthode times qui correspond à l'opérateur *
if(x!=null) {
  print(x * 2)    // ici, le compilateur sait que x n'est pas null,
                  // on peut utiliser x * 2 qui est équivalent à x.times(2)
)

Exemple en Ceylon :

Cube? cube = getCubeOrNull()
print cubs?.area()
if(exists cube) {      // permet de tester que la référence n'est pas null
  print cube.area()
} else {
  print "Cube is null"
}

Smart Cast

En Kotlin :

Object object = ...
if(object is String) {
  object.substring(1)  // pas besoin de caster l'objet en String,
                       // le compilateur le déduit de la clause if
}

En Ceylon :

Apple|Snail food = ...  // union type : food référence un objet soit de type Apple soit de type Snail.
if(is Apple food) {    // on s'assure que food est de type Apple
  food.eat()    // la méthode eat() n'existe que sur Apple, et pas sur Snail
                // dans le bloc du if, il n'est pas nécessaire de caster food en Apple pour l'appeler
}

On peut aussi considérer les deux exemples du paragraphe “null safety” comme des smarts cast : où le compilateur change le type de la référence d’un type nullable à un type non nullable.

Conclusion

Plus simple que Scala, ces langages pourraient répondre aux attentes de ceux qui veulent un langage sur la JVM qui soit plus expressif que Java.

Mais attention, Groovy les attend au tournant : la vérification statique du typage est en cours d’implémentation pour la prochaine version du langage : http://docs.codehaus.org/display/GroovyJSR/GEP+8+-+Static+type+checking

Il permettrait d’indiquer au compilateur d’effectuer un contrôle de type strict sur certaines classes : tout compte fait c’est peut-être juste ça que j’attendais moi !

Pour ceux qui ne connaissent pas Play! (et qui visiblemement ne lisent pas ni le blog d’Ippon, . . . → Lire la suite: Devoxx: Play! Framework 2.0]]> Deuxième retour de la conférence Devoxx qui bat en ce moment même son plein à Anvers en Belgique. J’ai assisté hier matin à la session sur Play! Framework 2.0 animée par Guillaume Bort et Sadek Drobi.

Introduction

Pour ceux qui ne connaissent pas Play! (et qui visiblemement ne lisent pas ni le blog d’Ippon, ni le Touilleur Express), il s’agit d’un framework orienté web, full-stack (contient toutes les briques nécessaires pour développer, déjà intégrées et configurées), et qui met l’accent sur la facilité et la rapidité de développement. Il a aussi la particularité de ne rien faire comme les autres… Pour résumer grossièrement, il s’agit d’un équivalent de Ruby on Rails pour le monde Java.

Guillaume Bort, créateur du framework, et Sadek Drobi, un des développeurs principaux, nous ont donc parlé de la prochaine évolution majeure du framework. Ils commencent par faire deux annonces:

• La sortie de la première bétâ de la future version 2.0.
• Typesafe (la société créée par Martin Odersky et Jonas Bonér, les créateurs de Scala et d’Akka respectivement), vont intégrer officiellement Play! 2.0 dans leur stack. Une intégration naturelle puisque Play 2.0! s’appuie fortement sur Scala, Akka et sbt… Guillaume Bort en profite également pour intégrer l’Advisory Board de Typesafe, où il sera plutôt en bonne compagnie puisqu’il y rejoint James Gosling et Doug Lea.

Historique

Sadek Drobi, commence par nous rappeler que le framework Play! est né chez Zenexity pour répondre aux besoins de projets réels, avant d’être rendu open source. Il nous fait un rapide rappel de l’évolution du web ces dernières années: d’abord un web statique, composé de simples pages HTML, puis un web dynamique, où on découvre que l’on peut manipuler une page dynamiquement, parfois avec certains excès, ce qui donne lieu à une phase de structuration qui est celle dans laquelle nous nous trouvons actuellement.

Selon Sadek Drobi, la prochaine étape qui nous attends est celle du temps réel, où les informations dans la page seront mises à jour en permanence (pensez Twitter…). Cette évolution du web entraine de nouvelles contraintes : besoin d’une gestion efficace des flux de données, une gestion plus facile de la concurrence, une meilleure élasticité au déploiement… Le but de Play! 2.0 est de répondre à ces nouveaux besoins tout en gardant la philosophie qui le caractérise: prise en main facile et intuitive, full-stack, rapidité de développement…

Nouveautés

Guillaume nous fait ensuite une démo rapide de la console Play! Il s’agit en fait de la console SBT. On peut y lancer des commandes comme compile ou run. SBT est wrappée dans le script “play” ce qui permet d’utiliser les même commandes que pour Play! 1.x (ex: play new, play run, play test…). On peut également lancer l’interpréteur scala depuis la console, et ainsi avoir accès directement aux classes de notre projet, y compris les templates compilées. On peut donc appeler une template à la main et voir tout de suite le HTML généré. Utile pour débogger…

Guillaume nous montre ensuite qu’on peut mélanger Java et Scala dans le même projet, avec le même système de recompilation à la volée, de rechargement à chaud, et d’affichage des erreurs directement dans le navigateur. Il nous présente aussi le nouveau système de templating. Exit Groovy, place à Scala.  L’avantage est que les templates sont compilées comme des fonctions Scala, et bénéficient de tous les avantages du typage fort. Si vous renommez un champ d’un bean, vous saurez dès la compilation que vous avez oublié de mettre à jour un template. Plutôt pratique…

Fin de la démo. Sadek reprend la parole pour nous parler des besoins grandissant d’asynchronicité pour les applications web. Lorsqu’on appelle un système externe pour récupérer des données (appel REST, WS, ou autre…), il n’est plus question de bloquer un thread de traitement des requêtes pendant qu’on attend la réponse. Lorsqu’on veut traiter un gros flux de données, il n’est pas question de tout charger en mémoire pour le traiter ensuite. Il faut mieux maîtriser la consommation des ressources (threads, CPU, mémoire). Il faut sortir des API bloquantes (genre InputStream), et mettre en place une méthode plus efficace que simplement passer un callback à une méthode asynchrone. Sadek nous dit qu’il faut faire du “reactive programming”: réagir à des évènements (une requête arrive, la réponse d’un processus long est arrivée…).

Il introduit ensuite la réponse de Play! à ce problème: le concept d’Iteratee et d’Enumerator. Concept apparement inspiré par le langage Haskell. De ce que j’en ai compris, il s’agit d’une sorte d’un producteur (l’Enumerator) qui notifie un consomateur (l’Iteratee) que de nouvelles données sont disponibles. L’Iteratee peut ensuite répondre de plusieurs façons:

• Continue: envoie moi encore des données, et traite les de cette façon là.
• Stop: arrête de m’envoyer des données (et libère potentiellement les resources)
• Error: tu m’envoies des données invalides.

Play! utilise Akka et le modèle d’acteur pour implémenter ces concepts. Ce point à vraiment l’air d’être une des nouveautés importantes, et je suis curieux de voir un exemple concret de mise en pratique de ce pattern…

Sadek nous parle ensuite de la couche de persistance. Il nous dit qu’il est illusoire pour eux d’essayer de faire une couche d’abstraction générique de la persistance, les technologies sous-jacentes étant trop différentes (bases relationnelles, bases NoSQL, etc…). Ils préfèrent implémenter des API spécifiques grâce à des modules spécifiques. Pour la version Scala, l’implémentation par défaut est Anorm (une simple couche au dessus de JDBC). Pour la version Java, EBeans est utilisé comme implémentation légère de JPA.

Sadek et Guillaume nous parlent ensuite de l’avantage d’utiliser SBT comme outil de build. SBT étant extensible, il est possible d’écrire des modules qui viendront étendre le cycle de vie de l’application. Par exemple, on peut déclarer des “compiled assets”, c’est à dire des resources qui seront compilées automatiquement par Play! en cas de changement, et dont les erreurs seront affichées dans le navigateur, de la même manière que pour les fichiers sources Java ou Scala. On peut par exemple gérer ainsi la compilation des CSS avec Less, ou bien des fichiers Javascript avec CoffeeScript.

Conclusion

En conclusion, la réécriture de Play! leur a apporté un certain nombre d’effets de bords bénéfiques, tels que de meilleures performances, mais aussi d’apporter du “type-safety” partout, y compris dans la couche présentation (les templates), et dans le fichier route (une route définie qui pointe vers une méthode de contrôleur inexistante sera détectée à la compilation).

Un bémol toutefois: il est à noter que Play 2.0 sera incompatible avec Play 1.x, tant au niveau des API que du moteur de templating, et qu’il n’existe pas de stratégie de migration bien définie. Les changements d’API devront être gérés à la main. Pour ce qui est des templates, il faudra soit les réécrire toutes (pas forcément très réaliste), soit espérer que quelqu’un fasse un module pour pouvoir utiliser le moteur de templating basé sur Groovy avec Play! 2.0. Les projets existants sous Play 1.x risquent de ne pas être migrés vers la version 2.0, mais combien de temps la branche 1.x sera-t-elle maintenue ? De même, Play! 2.0 propose une API Java et une API Scala. On peut se demander combien de temps ces deux APIs seront maintenues en parallèle, et si l’API Java ne sera pas dans le futur reléguée au deuxième plan.

Play! est souvent perçu comme le trublion des frameworks web, et génère souvent des réactions assez polarisées (on adore ou on déteste). Mais on ne peut que constater en étant à Devoxx qu’il jouit d’une popularité croissante en voyant le nombre talks lui sont consacrés cette année. Et l’annonce de son intégration à la stack Typesafe, qui offrira un support commercial, en est une preuve supplémentaire.

En voici un résumé, avec ma propre interprétation de ses slides et mes commentaires.

Spring est aujourd’hui un framework mature, ce qui signifie que son mode de fonctionnement et ses APIs ne changent pas . . . → Lire la suite: Les nouveautés de Spring 3.1 présentées à Devoxx]]> A Devoxx, il y a une session que je ne pouvais pas manquer: les nouveautés de Spring 3.1, par Costin Leau.

En voici un résumé, avec ma propre interprétation de ses slides et mes commentaires.

Spring est aujourd’hui un framework mature, ce qui signifie que son mode de fonctionnement et ses APIs ne changent pas à chaque nouvelle version. Cependant, le framework continue à évoluer en fonction des nouvelles technologies et tendances qui arrivent: essentiellement le Cloud Computing et les nouvelles versions de Java et Jave EE dans notre cas.

Au cours des deux dernières années, nous avons ainsi vu une explosion du nombre de plateformes sur lesquels on peut déployer son application:

• Java EE (JBoss 7, Glassfish 3, Websphere 8 )
• Tomcat 7 avec les Servlets 3.0
• Les platformes de Cloud: GAE (Jetty), Beanstalk (Tomcat), CloudFoundry (Tomcat), CloudBees (Tomcat)

Ces plateformes ont un certain dénominateur commun (l’API Servlet, en particulier), mais elles ont toutes des spécificités qui font qu’elles sont plus ou moins intéressantes en fonction du besoin et du moment (car ces spécificités changent avec le temps).

D’où l’importance d’être portable au niveau du déployement.

Commençons par un rappel historique: cette portabilité du déployement a toujours été le point fort de Spring: à l’origine, nous sommes nombreux à être passés à Spring car nous voulions pouvoir déployer la même application en développement (Tomcat) qu’en production (Websphere/Weblogic).

D’autre part, on a classiquement 4 environnements dans lesquels on déploie son application:

• Le développement
• Les tests d’intégration
• La pré-production (“staging” en Anglais)
• La production

Comment permettre à son application de se déployer de manière portable?

• JNDI est la technologie d’origine, proposée par J2EE. Bien entendu, son défaut est de ne fonctionner qu’avec un container. Dans mon expérience, elle est généralement compliquée à configurer pour les équipes de production.
• Les propriétés systèmes. C’est une solution appréciée des équipes de production, par contre en Java il nous faut un moyen d’y accéder de manière simple (ce que propose Spring).
• Des “application contexts” Spring différents. Une solution “pure” Spring qui est très répandue.
• Les “PlaceHolder” de Spring (avec le tag), qui est une amélioration de la méthode précédente.

Spring 3.1 vient ajouter une nouveauté: les profils de beans. On peut grouper les beans par type d’environnement cible, par exemple “dev”, “test”, “prod”.

• Typiquement on peut avoir deux beans avec l’id “dataSource”, qui sont instanciés en fonction du profil: une dataSource de “dev” et une dataSource de “test”.
• Cette configuration n’est pas nécessairement en XML, rappelons que Spring peut maintenant être configuré en Java (avec des annotations), ce qui permet plus de liberté dans ce cas.

Ces profils peuvent être activés via une configuration XML, ou via une API Java: il faut donc activer le bon profil au démarrage, par exemple en lisant une variable d’environnement.

Lors de la conférence, Costin a fait un sondage: la moitié des gens utilisent la configuration XML, la moitié via Java. Précisons, pour les gens qui croient encore que Spring ne se configure que par XML, que cette configuration “pure Java” est inclue dans Spring depuis 4 ans.

Cette configuration Java est généralement plus concise à utiliser pour de la configuration d’infrastructure: la définition de votre data source, de votre gestionnaire de transaction, etc… Elle est également plus puissante, car on peut plus aisément faire des branchements conditionnels ou du code spécifique qu’avec du XML.

Cette première partie de la conférence, très intéressante, a cependant un défaut: on n’y a pas rééllement parlé des nouveautés de Spring 3.1. La deuxième partie de la conférence par contre, était plus orientée sur les nouveautés de cette version 3.1.

L’abstraction du cache

Evidemment, avec l’achat de Gemfire par VMWare/SpringSource, le support du cache dans Spring est une priorité de Spring 3.1. La bonne nouvelle c’est que cette abstraction fonctionne avec plusieurs “fournisseurs” de cache, et pas que Gemfire: Ehcache (Terracotta), ConcurentMap (implémentation basique mais utile pour les tests), Redis (base NoSQL également sponsorisée par VMWare). D’autre part, des implémentations Infinispan (JBoss) et Websphere eXtreme Scale (IBM) sont en train d’être contribuées. Cette fonctionnalité est particulièrement importante pour moi:

• La JSR Cache commence à redémarrer après des années de stagnation: c’est donc intéressant d’avoir quelque chose de déjà utilisable.
• Dans un contexte “Cloud”, qui implique des applications multi-tenantes, avoir un cache distrbué est absolument essentiel.

Support des Servlets 3.0

Spring 3.1 va supporter l’API Servlet 3.0, avec Tomcat 7 ou GlassFish 3, tout en préservant la compatibilité Servlet 2.4.
On peut donc maintenant configurer son application Web sans fichier web.xml

Au niveau de Spring MVC, cela apporte la gestion des requêtes HTTP asynchrones. Cette fonctionnalité est particulièrement importante pour pouvoir monter en charge lorsqu’on a beaucoup de clients, et que l’on veut faire une application Web moderne, avec beaucoup d’appels Ajax (dont certains peuvent être asynchrones).

Au niveau de Spring MVC REST, un refactoring complet a été réalisé. Costin nous promet de meilleures performances, une API plus propre pour les utilisateurs avancés, tout en restant backward compatible.

A ce sujet, deux nouveautés sur l’annotation @RequestMapping sont intéressantes:

• “consumes”, pour indiquer le type de media consumé (le “content-type header”)
• “produces”, pour indiquer ce que l’on produit

On peut par exemple avoir la configuration suivante:
@RequestMapping(value="/foo", consumes="application/pdf")

Mises à jour de librairies

Au niveau de JPA, on peut désormais avoir le package scanning sans fichier persistence.xml, ce qui simplifie les applications avec une seule persistence unit.

Spring 3.1 va supporter nativement Hibernate 4.0, avec en particulier des packages spécifiques en fonction des versions (org.springframework.orm.hibernate3 et org.springframework.orm.hibernate4).

De même, Spring 3.1 supporte Quartz 2.x (nombreux changements dans l’API Quartz 2.0/2.1), avec compatibilité Quartz 1.5. D’où l’importance d’un système d’abstraction de la configuration, afin de pouvoir monter de version facilement.

Spring 3.1 supporte Java 7

• Utilisation au mieux de Java 7 si il est disponible, sinon Spring utilisera Java 5 ou 6 (oui Spring 3.1 est toujours compatible Java 5)
• Support de JDBC 4.1, en particulier pour JdbcTemplate
• Support de la nouvelle API Fork/Join arrivée avec Java 7

Cette dernière nouveelle concerne la programmation concurrente dans le contexte actuel: nous avons en effet de plus en plus de cores sur nos machines, mais ils sont généralement moins puissants. Donc si on n’utilise pas tous ces cores de manière optimale, les performances sont moins bonnes que sur certaines “vieilles” machines.
Spring permet donc d’avoir des pools d’objets spécialisés, qui “comprennent” l’API fork/join et s’optimisent automatiquement en fonction du nombre de cores disponibles sur le serveur.
Dans un environnement “cloud” cette fonctionnalité prend tout son sens: on peut rajouter ou enlever des cores en fonction des besoins, il est donc nécessaire d’avoir une application capable de s’optimiser automatiquement en fonction de ces changements.

L’avenir et Spring 3.2

Peu d’informations sur Spring 3.2, si ce n’est que le focus sera sur les technologies suivantes:

• Java EE 7
• JCache (JSR 107)
• JMS 2.0
• Bean Validation 1.1
• JPA 2.1
• JSF 2.2

De l’autre coté des serveurs les utilisateurs raffolent de ces applications enfin ergonomiques et qui fonctionnent sur . . . → Lire la suite: Tempête sur les RIAs]]> Ceci n’est pas un billet de fond mais un appel à commentaires :

• Adobe se désengage plus ou moins en douceur de Flex,
• MS va bientôt arrêter le support Silverlight,
• Google ne proposera jamais de support sur GWT.

De l’autre coté des serveurs les utilisateurs raffolent de ces applications enfin ergonomiques et qui fonctionnent sur les vieux coucous des services administratifs du CAC 40 équipé du bon vieil IE.

Que devons-nous faire en phase de choix :

• Revenir à du JS le temps que la tempête passe ?
• Miser sur la communauté pour assurer l’avenir de Flex et de GWT ?
• Miser sur les alternatifs : Vaadin,…?
• Traverser la tempête vitesse grand V et mettre du HTML5 partout ?

A vos commentaires.

Impliqué dès le début dans le projet, c’est avec enthousiasme qu’Ippon Technologies s’est engagé à devenir l’un des premiers sponsors de l’événement.

Le projet est en cours, mais vous pouvez déjà compter sur . . . → Lire la suite: Ippon Technologies sponsor de Devoxx France!!]]> LA grande nouvelle du jour est donc la tenue de Devoxx France dans 5 mois, du 18 au 20 Avril 2012 !

Impliqué dès le début dans le projet, c’est avec enthousiasme qu’Ippon Technologies s’est engagé à devenir l’un des premiers sponsors de l’événement.

Le projet est en cours, mais vous pouvez déjà compter sur une présence importante d’Ippon Technologies à l’événement: en tant que partenaire et sponsor de longue date des événements de la communauté Java en France, Ippon réaffirme une fois de plus son engagement dans notre plate-forme préférée!

Cette annonce, ainsi que la participation d’Ippon Technologies à l’événement, a été faite ce matin lors de la keynote d’ouverture de Devoxx 2011.

Pour ceux qui auraient participé à l’ESA Mars 500, et donc qui n’auraient pas attendu avec impatience Devoxx 2011: il s’agit tout simplement de la plus grande conférence Java en Europe, avec 3200 personnes et les speakers les plus prestigieux.

Ippon Technologies a d’ailleurs envoyé une délégation de 6 de ses consultants sur place, qui vont vous tenir au courant des dernières nouveautés via ce blog, notre compte Twitter et notre compte Facebook: pour tous ceux qui n’ont pas eu la chance d’aller à Anvers cette année, cela donnera un avant-goût de Devoxx France! Dépêchez-vous de vous inscrire, il ne reste plus que 5 mois!

Nous verrons comment est structurée la mémoire d’une JVM et comment allouer de l’espace en dehors de la Heap ?

Et ce, dans le but de pouvoir conserver les données en mémoire même pour . . . → Lire la suite: Java : Accès directs à la mémoire (off-Heap)]]> La zone mémoire la plus connue d’une JVM est la heap mais ce n’est pas la seule zone de stockage disponible.

Nous verrons comment est structurée la mémoire d’une JVM et comment allouer de l’espace en dehors de la Heap ?

Et ce, dans le but de pouvoir conserver les données en mémoire même pour les applications les plus consommatrices.

Points abordés :

• Quelles sont les méthodes pour instancier de la mémoire hors heap
• Les cas d’applications (Cache, Memory Mapped File)
• Performances
• Problèmes rencontrés

Introduction et théorie

Voici les différentes zones que l’on peut retrouver dans un process Java :

Process Java

On y trouve des zones techniques : JVM, OS.

Des zones de stockage de données : Mémoire Heap et native.

La zone d’échange entre la JVM et l’OS : Librairies.

La gestion de la memoire Java est parfois assez déroutante pour les débutants : les paramètres de gestion les plus connus sont ms et mx qui régissent la taille de la Heap alors que nous venons de voir que ce n’est pas la seule zone mémoire d’une JVM.

Java nio a introduit le principe de mémoire off-heap (java 1.4). Java 7 l’a étendu (JSR-203/NIO2).

Les objets concernés sont les ByteBuffers (java.nio.ByteBuffer) avec allocation directe (maximum de  2 Go par buffer).
Concrètement il s’agit d’un tableau de Bytes qui sera stocké dans la mémoire native.
La nature même du stockage (sous forme binaire) impose une sérialisation/désérialisation des objets.

Tout d’abord le tableau suivant montre pourquoi il faut privilégier la mémoire aux autres types d’accès.

Comparaison des coûts de lecture en fonction du type de mémoire

La conclusion semble évidente : pour des raisons de performances, il faut privilégier la mémoire locale à tout autre type de stockage.

Gabarge Collector et problématiques

Longtemps la taille maximale allouée à une JVM a été limitée par différents facteurs :

• Architecture 32 bits du processeur.
• Système d’exploitation hébergeant la JVM (taille maximale d’un processus, maximum de RAM supportée)

Mais aussi, et c’était souvent le premier seuil atteint, par le comportement du Garbage Collector.

Il s’agissait de trouver le meilleur ratio entre taille de la Heap et péjoration des performances dues aux traitements du Garbage Collector.
De même, bien que plus rare que dans les langages sans gestion automatique de la mémoire, un programme Java n’est pas à l’abri des fuites mémoires.

C’est pourquoi, malgré la multiplication des architectures et OS 64 bits, cette barière n’a que peut évoluée depuis les débuts de Java.
On peut la fixer à 3-4 Go.

Conscients de cette limite, les éditeurs tentent de réagir.

Oracle à introduit le collecteur G1 (Garbage first) en version 6 de Java SE.
Ce collecteur a pour but de réduire les temps de passage du GC.

Azul System, s’est aussi positionné, avec la Zing Virtual Machine (Pauseless Garbage Collection).

En attendant, il est tentant d’utiliser le stockage hors heap dans des applications Java.

Mémoire off-heap

Une belle définition sous forme de lapalissade pourrait être : « tout ce qui n’est pas dans la heap est off heap ».

Tout d’abord voyons comment est structurée la mémoire dans la JVM

A – Zones méthodes (Method Area)

Cette zone est essentiellement alimentée par le classloader.
Quand la JVM charge une classe ou une interface, elle place les informations nécessaires dans cette zone.
Cette zone est éligible au Garbage Collector. Quand une classe passe hors scope elle sera collectée lors du prochain passage du GC.
Cette zone est partagée (accessible à tous les process de la JVM).

1 – Pool constantes :

Contient toutes les constantes définies par l’application :

Littérales : int, long, float, double ou bien String.
Références vers les types, les champs et les méthodes.

2 – Code méthode :

Implémentation (bytecode) de toutes les méthodes utilisées par la JVM.

3 – Zone d’informations :

Contient différents éléments d’information sur les classes.
Champs de classe :

• Nom du champ.
• Type du champ.
• Modificateurs du champ.

Méthodes :

• Nom de la méthode.
• Type retourné.
• Nombre et type des paramètres.
• Modificateurs de la méthode.

En plus pour les méthodes non abstraites ou natives :

• Taille de l’opérande et des variables locales (utilisée pour frame stack).
• Table d’exception.

4 – Variables de classes

Les variables de classes sont partagées par toutes les instances de la classe. De plus elles ne sont pas liées à l’instanciation d’une classe mais créées au chargement de la classe.

B – Heap

Lorsque la JVM doit instancier un objet java, elle le fait dans cette zone.
On y retrouve les classes, les objets, les primitives Java.
Cette zone est nettoyée par le GC.

Cette zone est partagée (accessible à tous les process de la JVM).

NB : il y a une seule Heap et Method Area par JVM.

C – Threads

Cette zone n’est pas partagée.

Pointeur d’instruction :

Indique la ligne de code actuellement exécutée.

Java stack :

Stocke les primitives et les références.

Stocke l’état des méthodes invoquées (non natives) par le thread, l’état comprend les variables locales à la méthode (ThreadLocal), les paramètres d’appel ainsi que la valeur retournée par la méthode.

Chaque état est stocké dans des frames (un par méthode) dont la durée de vie est liée au cycle d’appel de la méthode.

Cette zone est nettoyée par le GC.

Cette zone est parcourue par le GC afin d’identifier les objets non référencés dans la Heap.

Frames :

Trois sections compose les frames.

Piles opérande

• Pile FIFO 32/64 bits utilisée pour le stockage provisoire des variables ainsi que des calculs intermédiaires.

Données

• Références RCP (Runtime Constant Pool).
• Références vers le pool de constantes utilisées par le thread.
• Résultats des retours de méthodes.

Variables locales

• Tableau contenant les variables locales de la méthode. Soit les variables dont la durée de vie est celle de la méthode ainsi que les paramètres d’appel.

Stack Frames

Méthodes natives

A l’image des Frames l’état des méthodes natives est stocké dans cette zone.
Mais contrairement à ces dernières, l’organisation est dépendante de l’OS et de l’implémentation de la méthode native.

Création d’objets en dehors de la heap Java

L’utilisation dans un programme Java de mémoire hors heap devra répondre aux problématiques suivantes :

• Accéder à la mémoire hors heap.
• Gestion de la mémoire.
• Référencement et accès à la mémoire off-heap.

A – Java Native Access (JNA)

JNA permet l’accès aux librairies natives (dll, so) à partir de code Java uniquement (sans utiliser JNI ou du C).
Une interface java décrit les méthodes et les structures de la librairie native.
Il n’y a pas de génération de code tout se fait au Runtime.

JNA est fourni avec certaines librairies natives courantes ainsi que des classes utilitaires d’accès à la mémoire native.

Plus d’informations :

Documentation : http://www.root-me.org/fr/Documentation/Hacking/Java-native-code-injection.html
Site web : https://github.com/twall/jna

Cette librairie fournie plusieurs méthodes pour créer des objets en dehors de la heap.

int value = 12345;
int offset = 0;
int size = 128;

// on crée un objet mémory
Memory m = new Memory(1024);

// on alloue l'espace mémoire
ByteBuffer buff = m.getByteBuffer(0, size);

offset = offset + size;

// On insère l'objet
buff.putInt(value);

// RAZ de la position courante du buffer
buff.flip();

// On récupère et affiche l'objet
System.out.println(buff.getInt());

// On déclare un deuxième buffer
ByteBuffer buff2 = m.getByteBuffer(offset, size);

// On insère l'objet
buff2.putInt(value + 1);

// RAZ de la position courante du buffer
buff2.flip();

// On récupère et affiche l'objet
System.out.println(buff2.getInt());

// on libère la mémoire
m.clear();

// méthode 2
// on crée un objet mémory
// et on insère directement les objets
Memory m2 = new Memory(1024);

// On insère l'objet
m2.setInt(offset, value);

// On récupère et affiche l'objet
System.out.println(m2.getInt(offset));

// on libère la mémoire
m2.clear();

B – Utilisation de la classe ByteBuffer

L’utilisation de la mémoire native avec cette API est simple, voire transparente.
Deux méthodes de création d’un ByteBuffer sont disponibles :

1. ByteBuffer.allocateDirect()
2. ByteBuffer.allocate()

Seule la première méthode instancie un objet en dehors de la heap.

Exemple de code :

byte[] bytes = ...;
// allocate native memory to store our object
ByteBuffer buf = ByteBuffer.allocateDirect(bytes.length);
buf.put(bytes);

Remarque : Le contenu stocké doit être de type tableau de byte, ce qui explique que le contenu stocké hors heap doit être sérialisable.

Nota Bene : Ceux qui on déjà codé en C/C++ ne devront pas s’attendre a retrouver l’équivalent de malloc.
En effet les possibilités offertes sont très limitées et le plus surprenant étant qu’il n’y a pas de méthode pour désallouer un objet stocké hors heap.

Comment ça marche alors ?
En réalité une méthode de libération de la mémoire est crée automatiquement (sun.misc.Cleaner) et sera appelée par le GC lors de son prochain passage.

Conclusion :

Tout comme pour la heap, l’espace est libéré par le GC lorsque l’objet n’est plus référencé par le code.
Tout comme la heap il n’y a pas de relation directe entre le moment ou l’objet est libérable et le moment ou il est effectivement libéré.
Donc il n’y a pas de magie, les objets hors heap sont bien sensibles au GC.

Toutefois :

• Pas de phase de marquage des objets.
• Pas de phase de compaction (réorganisation de l’espace mémoire) pendant le passage du GC.
• Le nettoyage de la mémoire hors heap est donc plus rapide que son homologue de la heap.

Il est possible d’appeler la méthode de nettoyage à tout moment (encore une fois en fouillant dans les profondeurs de l’API) :

Method getCleanerMethod = buffer.getClass().getMethod("cleaner", new Class[0]);
getCleanerMethod.setAccessible(true);
sun.misc.Cleaner cleaner = (sun.misc.Cleaner)getCleanerMethod.invoke(buffer,
   new Object[0]);
cleaner.clean();

C – Autres possibilité d’allocation directe

sun.misc.Unsafe

Son utilisation est un peu plus complexe, il s’agit de la classe qui est derrière ByteBuffer.allocateDirect().
Comme son nom l’indique cette classe est unsafe et doit donc être utilisée en toute connaissance de cause. En effet l’accès à une zone mémoire non allouée provoque immanquablement le crash de la JVM.
Pour plus de sécurité les constructeurs sont privés et la méthode de classe getUnsafe() ne peut être appelée que par un Bootloader (et donc par la JVM elle même).

Heureusement il est possible de contourner cette sécurité.

Méthode de récupération d’une instance :

private static Unsafe getUnsafeInstance() throws SecurityException,
NoSuchFieldException, IllegalArgumentException,
IllegalAccessException {
   Field theUnsafeInstance = Unsafe.class.getDeclaredField("theUnsafe");
   theUnsafeInstance.setAccessible(true);
   return (Unsafe) theUnsafeInstance.get(Unsafe.class);
}

Autres cas d’utilisation de la classe :
Cette classe permet de connaître l’adresse d’un objet stocké en mémoire.
Plus précisément la position d’un champ dans la zone mémoire allouée aux instances de la classe.

// Récupère une instance Unsafe
Unsafe unsafe = getUnsafeInstance();

// Réserve de la mémoire directe
Long allocateMemory = unsafe.allocateMemory(10);

// Récupération de l'espace d'allocation du champs code Commune
Field field = Commune.class.getDeclaredField("codeCommune");
Long offsetCodeCommune = unsafe.objectFieldOffset(field);

// On affecte une valeur à l'emplacement du champ
unsafe.putObject(allocateMemory, offsetCodeCommune, "325555");

NB : qui a dit qu’il fallait obligatoirement un setter public ?

MemoryMappedFile

Le contenu du fichier est mappé dans l’espace mémoire du process depuis le fichier source. Une fois le fichier chargé (ou une portion du fichier) tous les accès se font en mémoire.
Il en résulte des performances extrêmes par rapport aux méthodes traditionnelles qui utilisent les accès disques.

Cette méthode est la plus indiquée en cas de copie partielle ou totale d’un fichier.

File file = new File(path);

// Creation d'un memory-mapped file en lecture seule
FileChannel roChannel = new RandomAccessFile(file, "r").getChannel();

MappedByteBuffer mbb = roChannel.map(FileChannel.MapMode.READ_ONLY, 0,
   (int) roChannel.size());

// tableau de bits utilisé pour la lectre
ByteArrayBuffer bits = new ByteArrayBuffer();

while(mbb.hasRemaining()) {
   // on lit le prochain octet
   byte b = mbb.get();
   if (b == 10 || b == 13) {
      if (!firstLine) {
         // On ignore la première ligne (entête)
         firstLine = true;
      } else {
         // on affiche le contenu du fichier
         System.out.println(bits.toString());
      }

     // on passe à une nouvelle ligne
     // on réinitialise le tableau
     bits = new ByteArrayBuffer();
     } else
       // on ajoute l'octet au tableau
       bits.write(b);
}

// on ferme le canal
roChannel.close();

// on vide le buffer
mbb.clear();
...

Particularités :

• L’OS charge/décharge le contenu du fichier selon les besoins.

• Utile pour les fichiers extrêmement volumineux.

• Ou à l’inverse lorsque seul un fragment d’un fichier est utilisé.

Exemple

Mise en cache d’un extrait de la liste des communes mondiales de plus de 1000 habitants (+/- 114000) à partir d’un csv. Le code présenté a été teste avec la JVM OpenJDK 1.7 sur MAC (elle apporte un MBean de monitoring de la mémoire allouée par AllocateDirect()).

Quatre versions :

1. Une classique avec une Map
2. Une directbuffer en utilisant serialisation java
3. Une directbuffer en utilisant externalizable java
4. Une unsafe

1)

public class MemoryCache {

private Mapdata = new HashMap();

public void put(Object key, Commune object) throws IOException {
data.put(key, object);
}

public Object get(Object key) throws ClassNotFoundException, IOException {
return data.get(key);
}
…

}

2) & 3)

public class NativeMemoryCache {
private Map data = new HashMap();

public void put(Object key, Serializable object) throws IOException {
 byte[] bytes = serialize(object);
 // allocate native memory to store our object
 ByteBuffer buf = ByteBuffer.allocateDirect(bytes.length);
 buf.put(bytes);
 buf.flip();
 data.put(key, buf);
}

public Object get(Object key) throws ClassNotFoundException, IOException {
 ByteBuffer buf = data.get(key).duplicate();
 byte[] bytes = new byte[buf.remaining()];
 buf.get(bytes);
 return deserialize(bytes);
}
…

}

4)

public class NativeMemoryCacheUnSafe {

/**
* Création de la map pour stocker la clé
* ainsi que l'adresse de l'objet en mémoire native
*/
private Map data = new HashMap(120000);

/**
* Objet Unsafe pour accéder
* à la mémoire native
*/
private static Unsafe unsafe = null;

/**
* Offset de stockage dans la mémoire native
*/
private static Long offset = new Long(0);

static {
 try {
   unsafe = getUnsafeInstance();
 } catch (SecurityException e) {
   System.out.println("Exception de sécurité :" + e);
 } catch (NoSuchFieldException e) {
   System.out.println("Impossible d'accéder au champ de la classe Unsafe :" + e);
 } catch (IllegalAccessException e) {
   System.out.println("Impossible d'accéder à la classe Unsafe :" + e);
 }
}

public void put(Long key, long codeCommune, String nomCommune, double latitude,
double longitude, String codePays, String codeRegion, String codeAdministratif,
int population, String timeZone) throws IOException,
SecurityException, NoSuchFieldException, IllegalArgumentException,
IllegalAccessException {
//Taille max d'un objet (bytes)
Long allocateMemory = unsafe.allocateMemory(400);

unsafe.putObject(allocateMemory, offset, new Commune(codeCommune, nomCommune, latitude,
 longitude, codePays, codeRegion, codeAdministratif, population, timeZone));

data.put(key, allocateMemory);
}

/**
* @param key identifiant unique de l'objet
* @return
* @throws ClassNotFoundException
* @throws IOException
* @throws SecurityException
* @throws NoSuchFieldException
* @throws IllegalArgumentException
* @throws IllegalAccessException
*/
public Commune get(Object key) throws ClassNotFoundException, IOException,
SecurityException, NoSuchFieldException, IllegalArgumentException,
IllegalAccessException {

 Long adresse = data.get(key);
 return (Commune)unsafe.getObject(adresse, offset);
}

…

}

Résultats

used : La quantité de mémoire réellement utilisée par l’application.
committed : La quantité de mémoire qui a été réservée auprès du système d’exploitation.

Paramètres JVM : -X:+AggressiveHeap

Test 1.

Test 2.

Test 3.

Test 4.

Frameworks utilisant l’accés direct à la mémoire

Terracota BigMemory (ehcache) : stockage de données dans la mémoire native
Coherence : Coherence propose le stockage off heap dans son cache
DirectMemory : Equivalent open source de Big Memory
Huge collections : Framework permettant de manipuler de grande collection en utilisant la mémoire native

Références

Java virtual machine specifications : http://java.sun.com/docs/books/jvms/
The Structure of the Java Virtual Machine : http://java.sun.com/docs/books/vmspec/2nd-edition/html/Overview.doc.html

Options de la JVM relatives à la mémoire directe.

-d64
Permet de passer la JVM en mode 64bits, utile pour adresser plus de mémoire.

-XX:MaxDirectMemorySize= ou -Dsun.nio.MaxDirectMemorySize=
Permet de définir la mémoire maximale réservées pour la mémoire off heap.

-XX:+PageAlignDirectMemory ou -Dsun.nio.PageAlignDirectMemory=true
Permet de s’assurer qu’un espace de mémoire native est alignée sur une page mémoire. Avant le JDK7, une page entière (ou plus) était allouée quelle que soit la taille de l’objet (4096 octets sur une majorité d’OS).

Conclusion

L’exemple retenu n’est pas le plus favorable aux cas d’utilisation de la mémoire off-heap, c’est pourquoi il met en exergue les inconvénients de cette solution.

L’utilisation de la mémoire native est une solution à envisager si votre programme est très consommateur en mémoire et pas forcement pour les programmes affectés par les passages du GC.

Ce n’est donc pas forcement le miracle attendu dans le sens ou ne vous dispensera pas des tracas du GC.

De plus le programme consomme temporairement autant de heap qu’un programme traditionnel (creation d’objets avant de stocker off-heap).

Enfin la sérialisation est coûteuse en terme de performances (mais seuls les programmes les plus exigeants la verront comme un véritable obstacle).
C’est pourquoi, sauf à utiliser la classe Unsafe, l’utilisation de la mémoire native est moins performante que son homologue Heap.

Conditions idéales d’utilisation de la mémoire native :

• Idéal quand la volumétrie de données est très importante (> 2 Go).
• Quand les données sont stables dans le temps (sinon les données sont collectées par le GC).
• Et enfin quand les données sont sérialisables.

L’utilisation des classes comme Unsafe est très dangereuse et réclamera une longue mise au point afin d’éviter un crash de la JVM avec pour seuls indices un code retour 139 (Segmentation violation) ou 134 (Dump core).
Pour les programmes affectés par le passage du Garbage Collector, c’est une solution parmi d’autres :

1. Tuning de la JVM et du GC
2. Création d’un pool d’objets réutilisables (crées à l’avance et jamais libérés).

Le code source est disponible ici : Source

Au menu, nous vous proposons de nouvelles rubriques détaillant nos offres, nos compétences, nos références et partenaires… Ainsi qu’une mise à jour des parties recrutement et société, avec de nouvelles pages pour nos agences de Bordeaux et Nantes.

Nous avons voulu mettre l’accent sur . . . → Lire la suite: Nouvelle version du site d’Ippon Technologies]]> La nouvelle version de notre site http://www.ippon.fr est en ligne !

Au menu, nous vous proposons de nouvelles rubriques détaillant nos offres, nos compétences, nos références et partenaires… Ainsi qu’une mise à jour des parties recrutement et société, avec de nouvelles pages pour nos agences de Bordeaux et Nantes.

Nous avons voulu mettre l’accent sur l’esprit d’Ippon, notre participation aux communautés Java et agile, et nous avons intégré le site avec ce blog et nos comptes Twitter et LinkedIn, afin de permettre une meilleure interactivité avec nos visiteurs.

Au niveau technique, car nous savons que c’est ce qui intéresse avant tout les lecteurs de ce blog:

• En tant qu’experts Liferay, il était évident pour nous que  le site devait être entièrement développé et mis en page sur un Liferay 6. Nous avons réalisé quelques portlets spécifiques, ainsi que notre propre template, mais l’essentiel du site est réalisé avec les fonctionnalités standard de Liferay. Nous avons particulièrement apprécié :
  • Les nouvelles fonctionnalités de CMS proposées par Liferay 6
  • La manière dont Liferay nous permet de gérer le SEO (Search Engine Optimization), à la fois simple et puissante
• Nous sommes hébergés sur le cloud Ippon, qui est une plateforme Open Nebula (et sur laquelle nous hébergeons également nos clients qui le désirent)
• Nous avons géré tous nos développements sur la plateforme de développement interne d’Ippon: SVN et Trac en particulier. C’est la même plateforme que nous utilisons pour les forfaits réalisés dans nos locaux.

Si vous êtes encore sous IE6 il faudra attendre la semaine prochaine pour un accès dégradé.

Bonne navigation,

La semaine dernière, à l’occasion de la disparition de Steve Jobs, Geoffray évoquait l’héritage technologique que celui-ci avait apporté à la communauté des développeurs en général et Java EE en particulier. N’en déplaise aux intégristes (comme le Molah Stallman), aux grincheux . . . → Lire la suite: L’héritage de Dennis Ritchie (1941-2011)]]>

Dennis Ritchie (debout) et Ken Thompson devant un PDP-11 en 1972 Chez Bell.

La semaine dernière, à l’occasion de la disparition de Steve Jobs, Geoffray évoquait l’héritage technologique que celui-ci avait apporté à la communauté des développeurs en général et Java EE en particulier. N’en déplaise aux intégristes (comme le Molah Stallman), aux grincheux ou aux incultes, cet apport est bien réel et la micro informatique de 2011 doit beaucoup à l’Apple II, au Macintosh ou à Next Step. Evidemment quasiment toutes ces “inventions” attribuées à Jobs ne sont que du recyclage d’idées mises au rebut par d’autres (Xerox pourrait aujourd’hui être à la place d’Apple ou Microsoft), mais n’est-ce pas ce que tous les innovateurs font : aller plus haut en montant sur les épaules des géants qui les ont précédés ? Les épaules sur lesquelles Jobs est monté sont nombreuses, mais celles de Dennis Ritchie sont probablement les plus larges. Car si la micro-informatique doit beaucoup à Jobs, l’informatique en général doit encore plus à Dennis Ritchie qui nous a quitté le week-end dernier à l’age de 70 ans.

L’histoire

A la fin des années 60, Ritchie travaillait aux Bell Laboratories avec Ken Thompson au développement d’un nouvel OS : Unix. La première version du système fut écrite en assembleur, mais rapidement, ils réalisèrent qu’ils auraient besoin d’un langage de plus haut niveau pour développer la seconde version, notamment pour gérer les structures de données indispensables au différentes fonctions de l’OS. La première tentative en Fortran fut rapidement abandonnée et  Ritchie proposa de créer un  nouveau langage basé sur le language B créé par Thompson quelques années plus tôt.

Plusieurs légendes courrent au sujet du langage B : Thompson l’aurait nommé de la sorte d’après le nom de sa femme “Bonnie” ou moins romantique d’après le nom du language BCPL dont il était inspiré. J’avais pour ma part entendu raconté que le B était pour Bell. Toujours est-il que l’itération suivante s’appelerait logiquement le language C.

La langage B était interprété et comme Ritchie et Thompson avaient autant besoin de rapidité que de flexibilité, il décidèrent que le C serait compilé pour produire un code proche de la machine.

La première version du C n’était pas très différente de celle d’aujourd’hui quoiqu’un peu moins étoffée. Les types étaient déjà là ainsi que les fameuse structures de données (struct{};pour les intimes).

En résumé, C fut inventé pour pouvoir écrire un programme et ce programme était le noyau Unix, rien que ça…

En 1973, Ritchie publia un article scientifique sur le langage C et 5 ans plus tard, lui et son collègue Brian Kernighan (qui avait rédigé les premiers tutoriels sur C et qui força un peu la main de Ritchie) publièrent le classique “C programming language“.

Bell ayant laissé ouvert et accessible le code source d’Unix, il se répandit avec le C dans les université comme une trainée de poudre pour atteindre le succès qu’on lui connait.

L’héritage

Est-il besoin d’expliquer l’importance de ces deux inventions sur ce blog ? Je ne pense pas (ou alors vous vous êtes vraiment perdu). Je résumerai juste par deux schéma trouvé sur le Web :

History of programming language (sur http://civilprogrammers.blogspot.com)/

dans ce premier schéma qui présente un aperçu des principaux langages par décénie et héritage, on voit bien que tous les langages utilisés aujourd’hui ont C comme ancêtre commun et gardons à l’esprit également que leur compilateur et/ou environnement d’éxécution ont été ou sont encore écrit en C.

Historique simplifié d'Unix (Wikipedia)

Ce deuxième schéma illustre une version simplifiée de la galaxie Unix. En parcourant ce diagramme on se rend compte qu’en dehors de Windows (qui reste donc l’OS grand public le plus propriétaire mais est malgré tout développé en C), tous les autres sont basés sur Unix. Les deux premières cases du haut c’est Ritchie, la troisième colonne c’est Steve Jobs (au passage on peut voir, que Darwin, la version de BSD qui constitue la base de Mac OS X a son code ouvert (en fait open source mais avec une licence non reconnue par l’OSI)). Ainsi, si Jobs fait partie de l’héritage de beaucoup d’entre nous Ritchie fait partie de notre Héritage à tous.

C’est parfois bon de se sortir le nez le l’IDE pour se rappeler que nous avons une histoire. Car, Etre compétent ou expert techniquement ne suffit pas pour faire un bon développeur. La culture informatique doit également s’appuyer sur le passé. Comprendre la raison d’être des outils que nous utilisons et connaître leurs ancêtres est capital. Ca évite de dire des imbécilités ou de ré-inventer la roue.

“Celui qui ne connait pas l’histoire est condamné à la revivre”
K. Marx

#include <stdio.h>

main(int argc, *char argv[]){
	if(argc!=1)
		exit(1);
	else {
		char *dennis="Dennis";
		char *world="World";
		if(strcmp(dennis,argv[0])==0) {
			printf("Hello %s says %s n",world,dennis);
			printf("Good bye %s says the %s n",dennis,world);
			exit(0);
		}
	}

L’une des technologies les plus populaires dans le monde Java EE est sans aucun . . . → Lire la suite: JPA : une magie qui se mérite (retour aux sources de JPA)]]> Cet article fait partie d’une série sur les technologies incluses dans Java EE 6. Vous pouvez également lire l’article d’introduction de cette série : Java EE 6 ici et maintenant et celui sur JSF : JSF je t’aime, moi non plus

L’une des technologies les plus populaires dans le monde Java EE est sans aucun doute JPA. Il suffit de voir le nombre de livres et d’articles sur le sujet. Toutefois, si JPA est très répandu, il s’agit aussi de l’une des spécifications Java EE les moins bien maîtrisées par les développeurs et donc une source récurrente d’échecs des projets. Fort de ce constat je ne vais pas m’apesentir sur les nouveauté de JPA 2.0 dans ce post (en dehors de l’API criteria, celles-ci sont pluôt à la marge) pour me permettre de faire un retour aux sources sur JPA qui pourra profiter à certains. Ceux qui pensent maîtriser ces concepts pourraient être quand même intéressés par la fin de la’article qui traite de l’extended persistence context et de ses mérites.

Une “magie” complexe

La popularité de JPA et les échecs que cette techno engendre sont probablement liées au mélange de magie, de concepts compliqués qu’elle camoufle et de dissimulation de ces concepts au sein de frameworks destinés à faciliter son utilisation. La magie et les raccourcis offert par Spring (entre autres) permettent  de se lancer dans l’utilisation de l’outil sans avoir besoin de trop comprendre les couches sous-jacentes. Lorsque l’on arrive dans des cas concrets qui posent des problèmes, une grande partie des développeurs désinvestissent l’outil en critiquant ses limitations sans chercher à creuser plus avant. Parce que JPA nous fait sortir du confort du code pour aller nous battre avec des notions parfois mal digérés de gestion de transaction et base de données, il reste une énigme pour beaucoup. Certains développeurs pensent que le concept d’ORM en général et JPA en particulier permet de négliger SQL et les mécanismes bas niveau d’échange avec la BDD en les ramenant au rang de technologies inférieures. En pensant cela ils commettent une erreur : JPA rend l’utilisation de ces technologies plus facile et puissante mais ne nous permet pas des les occulter totalement. Il est un facilitateur pas une technologie de substitution.

Les 4 piliers de JPA

Schema Global du fonctionnement de JPA

JPA s’inscrit autour de ces 4 notions fondamentales :

• Les entités
• Les Persistence Units (au runtime on les manipulera via la classe PersistenceManagerFactory)
• L’Entity Manager (ou persistence manager)
• Les transactions

Le schéma ci-contre illustre le fonctionnement de JPA et comment ces 4 éléments fonctionnent ensemble. Pour synthétiser :

• La Persistence Unit organise les meta données qui définissent le mapping entre les entités et la base
• La Persistence Manager Factory récupère ces metas données de la Persistence Unit et les interprètent pour créer des Persistence Manager
• Le Persistence Mangager gère les échanges entre le code et la base de donnée, c’est à dire le cycle de vie des entités
• Enfin, le travail du Persistence Manager est englobé dans une Transaction. Cette dernière peut éventuellement gérer les opérations de plusieurs Persistence Managers comme un traitement unitaire.

Sans faire un cours exhaustif, il parait intéressant de faire un point sur les concepts clés liés à chacune de ces notions clés

Les transactions

Les transactions ne faisant pas stricto sensu partie de JPA, mais étant une composante indispensable au fonctionnement et donc à la compréhension de cette technologie, il est intéressant de commencer notre tour d’horizon par un rappel sur les concepts liés au transactionnel. Les transactions sont en effet aussi importantes que les mécanismes de persistence décrits plus loin. Sans elles les données échangées avec la base risqueraient d’être corrompues ou incohérente. C’est pourquoi il est important de vérifier que le périmètre des transactions soit bien défini lors de l’interaction de votre code avec la base de données.

L’objet de ce post n’est pas de faire un cours magistral sur le transactionnel, mais il me semble intéressant de rappeler quelques concepts de base puisqu’on parle de base de données et de persistence.

Retour sur les différentes APIs transactionnelles

Une transaction est un regroupement d’instructions SQL effectuant un traitement fonctionnel atomique (par exemple l’ajout d’un article dans un panier d’achat accompagné d’une décrémentation des stock pour la référence concernée). Ce regroupement est orchestré à l’aide d’instructions SQL dédiées comme : BEGIN, COMMIT ou ROLLBACK. Bien sûr, si on ne souhaite pas agir à si bas niveau on aura plutôt recours en Java à des API chargées d’automatiser la gestion des transactions pour nous. A cette fin, nous disposons de trois possibilités :

• Les transactions gérées par JDBC
• Les transactions de type Resource-local
• Les transactions gérées par  JTA

Les entité et le Mapping

JPA permet donc d’associer des objets dans notre code à des données dans une ou plusieurs bases. Les metas données du mapping (sous forme d’annotations) apportent la souplesse indispensable qui évite d’avoir un modèle de données mémoire totalement calqué que le modèle de donnée relationnel dans la base. On pourra ainsi gérer les colonnes associées à un champ (avec @column), créer une entité sur plusieurs tables (avec @SecondaryTable) ou gérer des champs ne devant pas être stockés (avec @Transient). Bien sûr la magie n’est pas absolue et il peut arriver un moment où votre structure de base de données est trop complexe pour assurer un mapping satisfaisant et où le choix de JPA peut commencer à être remis en cause. Une notion qu’il est capitale de comprendre est la persistance transitive : les associations entre entités avec les fameux @OneToOne, @OneToMany ou @ManyToMany. Le débutant en JPA rencontrera très vite ses premiers problèmes avec ces concepts. Soit parce que les associations déclencheront des chargements en cascade et créeront des grappes d’objets monstrueuses en mémoire, soit parce qu’il aura eu recours au mécanisme de Lazy loading qui peut devenir un cauchemar si on ne maîtrise pas le cycle de vie des entités et les concepts liés au transactionnel. On se reportera à la documentation des annotations JPA d’Hibernate pour avoir une liste exhaustive des possibilités de mapping disponibles dans JPA 2.

La Persistence Unit

C’est le point de départ du moteur JPA. Elle permet de lister les entités à manager et la façon dont elles sont mappées vers la base. Elle indique également le type de transaction utilisée lors des échanges avec la base. Elle est constituée à partir de trois parties :

1. Les meta données sur les entités (sous forme d’annotations, elles peuvent être surchargées par du XML)
2. Le descripteur de la Persistence Unit : le fichier de configuration Peristence.xml qui permet de configurer la connexion à la base et la nature des transactions et des paramètres spécifiques à l’implémentation de JPA utilisée.
3. La Persistence Manager Factory : Objet au runtime représentant la configuration complète de la persistence unit. Cette factory permet de créer un ou plusieurs persistence manager fournissant les services nécessaires à la gestions des entités

Mais n’oublions pas la plomberie JDBC sous JPA et la fameuse datasource, point de départ à la connexion vers la base…

JDBC et pool de connexion

JDBC reste donc la brique de base pour interagir avec la base de données et comme a priori votre application effectuera plusieurs requêtes simultanément vers la base vous avez besoin de fournir à JPA un pool de connexions JDBC. Dans un container Java EE tout cela se fait en général en définissant une data source, soit via un fichier (comme dans Glassfish ou JBoss) soit via une interface d’admin (comme dans Websphere). Cette data source est ensuite appelée via JNDI dans le fichier persistence.xml. La datasource consitue donc un pool de connexions JDBC. son rôle est de pouvoir vous fournir une connexion déjà “prête à l’emploi” (ouverte) quand vous voulez requêter la base et de faire le ménage quand un échange s’est mal passé (timeout, connexion mal fermée, etc…). Ce pool est fourni avec votre serveur d’application. exemple de data source JBoss :

<?xml version="1.0" encoding="UTF-8"?>
<datasources>
	<local-tx-datasource>
		<jndi-name>DefaultDS</jndi-name>
		<connection-url>jdbc:hsqldb:/Data/hypersonic/localDB</connection-url>
		<driver-class>org.hsqldb.jdbcDriver</driver-class>
		<user-name>sa</user-name>
		<password/>
		<min-pool-size>5</min-pool-size>
		<max-pool-size>20</max-pool-size>
		<idle-timeout-minutes>0</idle-timeout-minutes>
	</local-tx-datasource>
</datasources>

La plupart des containers légers permettent de faire la même chose, quasiment tous fournissent un gestionnaire de Pool JDBC. Pour les utilisateurs de Spring, il y a dans le framework de quoi déclarer un bean Datasource auquel on pourra adjoindre le pool JDBC de son choix. Je vous laisse le soin de lire cette doc croustillante qui fourmille de trolls vintage sur Java EE, (heu… pardon J2EE). Toute pique mise à part, Spring sera très utile pour gérer cet aspect ainsi que les problématiques transactionnelles dans un environnement Java SE, l’alternative étant de créer ce pool dans votre code. Quoiqu’il en soit, on se gardera bien de définir sa connexion JDBC dans le fichier persistence.xml car celle-ci ne permet pas (en standard) de choisir la nature du pool utilisé. Ainsi si votre implémentation JPA est hibernate, déclarer votre connexion JDBC dans persistence.xml vous amènera à utiliser le pool de connexion Hibernate par défaut qui n’est pas recommandé en production. Des propriétés propres à Hibernate permettent dans persistence.xml d’activer d’autres gestionnaires de pool fournis par le framework comme C3PO ou Proxool. Ces gestionnaires sont également peu recommandés, on essaiera d’utiliser en priorité le gestionnaire de pool du serveur d’application.

Le fichier persistence.xml

Là non plus je ne rentrerai pas dans les détails de la configuration du fichier de persistence. Je donnerai juste deux versions de la même unité de persistence. L’une avec une gestion du transactionnel et de la datasource au niveau container :

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
        <persistence-unit name="myPu">
		<provider>org.hibernate.ejb.HibernatePersistence</provider>
		<jta-data-source>java:/DefaultDS</jta-data-source>
		<properties>
                        <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect" />
		</properties>
	</persistence-unit>
</persistence>

La persistence unit définie dans ce fichier exploite la Datasource définie plus haut. Elle utilise Hibernate comme implementation JPA d’où la propriété hibernate.dialect propre à cette implémentation. La deuxième PU, définie une connexion et un pool JDBC géré en local dans l’application (en l’occurence par Hibernate)

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0"
	xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
	<persistence-unit name="myPu" transaction-type="RESOURCE_LOCAL">
	<provider>org.hibernate.ejb.HibernatePersistence</provider>
		<properties>
                        <property name="javax.persistence.jdbc.driver" value="org.hsqldb.jdbcDriver" />
                        <property name="javax.persistence.jdbc.user" value="se" />
			<property name="javax.persistence.jdbc.password" value="" />
                        <property name="javax.persistence.jdbc.url" value="jdbc:hsqldb:/Data/hypersonic/localDB" />
			<property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect" />
		</properties>
	</persistence-unit>
</persistence>

Spring propose une configuration en partie propriétaire dans son fichier de configuration pour la Datasource, puis dans persistence.xml, ce qui n’est pas toujours très clair. Comme on parle ici de Java EE , on se reportera à la documentation du Framework printanier qui fait pousser le XML,  pour plus d’informations sur ce dernier.

La gestion des persistence managers

La aussi il y a plusieurs possibilités pour gérer le cycle de vie des persistence manager JPA :

1. Géré par l’application dans le code en créant des instances via le Persistence Manager Factory
2. Géré par un framework du type Spring, Seam  (si on on est sur un serveur léger). Cette solution est techniquement équivalente à la première mais vous décharge d’avoir à gérer les instanciations
3. Dans le cas d’un serveur Java EE, ceux-ci sont gérés par le container ce qui permet par exemple de partager les mêmes persistence units entre plusieurs war au sein d’un même EAR

Le persistence manager Factory

Le chargement de la persistence unit (par le serveur ou l’application) donne lieu à la création d’un objet immuable : le persistence manager factory (ou entity manager factory) qu’on va récupérer automatiquement dans un context Java EE  via :

@PersistenceUnit
private EntityManagerFactory pu;

si vous devez le faire à la main (sans un container ou framework qui le fait pour vous) cela donnera

EntityManagerFactory entityManagerFactory=Persistence.createEntityManagerFactory("my_pu");

Le code précédent bootstrap JPA et déclenche la lecture du Persistence Context “my_pu”. Ce code est comme on s’en doute extrêmement coûteux, aussi on fera en sorte de ne lancer qu’au démarrage de l’application. On travaillera rarement avec l’EntityManagerFactory et on préferera demander au container directement un EntityManager.

Au coeur du Persistence manager

Le persistence manager (ou entity manager, la littérature utilise l’un ou l’autre) est l’API responsable de gérer le cycle de vie des entités JPA. Au delà des échanges explicites avec la base de données,  il est en charge de vérifier l’état des entités qu’il manage pour propager les modifications automatiquement vers la base et gérer le cache  de niveau 1 permettant d’optimiser les accès SQL. Pour l’obtenir à partir du container on utilisera

@PersistenceContext
private EntityManager em;

si on veut le faire à la main (après avoir récupéré l’entityManagerFactory avec le code ‘”à la main” précédent):

EntityManager em=entityManagerFactory.createEntityManager();

Dans ce cas gardez à l’esprit que vous devrez gérer le cycle de vie de l’entityManager vous-même.

Une fois cela fait, nous parvenons enfin au coeur de JPA avec le Persistence Manager dont les responsabilités sont les suivantes :

• Gérer les instances des entités : l’API du Persistence manager permettent de gérer les entités. Cette API dispose des méthodes pour créer, chercher, requêter, mettre à jour et détruire les instances des entités. Ce faisant, il gère les quatre états possibles pour chaque objet entité : transient, persisté, détaché et détruit. (c.f. le schéma sur le cycle de vie ci-dessous)
• Maintenir le context de persistance (Pesistence Context en VO) : Le contexte de persistance correspond à un cache mémoire des objets entité qui ont été chargés via le persistence manager. C’est le point d’entrée pour l’optimisation des performances dans la technologie JPA. vous le connaissez probablement aussi sous le nom de cache de premier niveau. Notez aussi que le terme Persistence Context est aussi parfois utilisé à la place de Persistence Manager (ou Entity Manager ) bien que ce ne soit pas exactement la même chose.
• Réaliser des contrôles automatiques des objets managés (dirty checks dans le texte) : l’état des objets présents dans le contexte de persistance est automatiquement surveillé pendant toute la durée de vie de ce dernier. Quand un événement de “flush” intervient sur le persistence manager, les modifications detectées par ce mécanisme sont poussées vers la base de données  sous forme de de commandes SQL Lorsque une instance d’entité entre dans l’état “détaché” (detached) ses modifications ne sont plus surveillées.

Le persistence manager travaille à plus haut niverau que le SQL. Grace aux annotations de mapping, il comprend que les données transitant depuis la base ont une structure objet (l’entité) et que cette structure à un cycle de vie (voir ci-contre).

Scoper le persistence context : une approche trop souvent négligée

Le persistence Manager (et par association le contexte de persistence) est souvent victime d’une méconnaissance des développeurs qui le pensent lié à la connexion avec la base ou à la durée de vie d’une transaction.  Cette erreur provient principalement des architectures stateless dont le framework Spring a fait la promotion depuis ses débuts. A cause de cette vision simpliste et restrictive, beaucoup de développeurs considèrent comme une mauvaise pratique (voire ignorent complètement) le fait de laisser ouvert le persistence manager pour une durée supérieure à une transaction ou une requête HTTP et correspondant à un cas d’utilisation de leur application. En fait le persistence manager est bien plus polyvalent que l’approche hyper partielle et pauvre prêchée par Spring. Oui, il peut être stateful (le mot est lâché), et donc laissé ouvert le temps de réaliser un cas d’utilisation complet (plusieurs écrans et actions de l’utilisateur). Contrairement à ce qu’on pourrait craindre, le persistence manager ne laissera pas la connexion vers la base ouverte tout le temps de sa durée de vie mais saura se reconnecter de manière transparente si le besoin s’en fait sentir.

Le mauvais réglage du scoping du Persistence Manager est la cause principale des critiques adressées à JPA. Avoir recours à des outils ou patterns qui ne permettent que de l’associer à la requête HTTP ou à la transaction en cours amène les développeurs à bricoler des solutions de contournement qui sont autant de mauvaises pratiques : comme le hideux pattern Open Session in view, une redéfinition du mapping JPA pour mettre en Fetch.Eager des associations qui auraient du rester lazy ou du requetage HSQL en pagaille pour  récupérer la grappe d’objets nécessaire pour traiter la requête et ses suites (comme des échanges Ajax par exemple). Comme je l’ai écrit dans de précédents articles, si Spring a été un apport précieux pour la mise en place de bonnes pratiques en terme d’architecture, on atteint là ses limites qui sont liées à des choix idéologiques de ses concepteurs qui n’ont autorisé pendant très longtemps qu’une approche purement stateless des architectures.

Ce qu’on doit faire pour que le persistence manager ait une durée de vie supérieure à la requête HTTP, c’est le gérer en mode stateful. C’est cette approche qui permettra de gérer un scope conversation comme le fait Seam 2 depuis 2006 et comme le propose CDI en standard dans Java EE 6. Cette approche nécessite de faire attention où le persistence manager est stocké, car il ne doit pas être dans un scope partagé (scope application par exemple) puisqu’il n’est pas thread safe. Voyons comment Java EE 6 gère ce mécanisme.

Le peristence context étendu

Depuis Java EE 5,  nous avons la possibilité de créer un persistence context étendu. Comme dit, plus haut, c’est un persistence context qui reste actif au dela de la transaction (mode par défaut du persistence context).

Avoir recours à un Persitence context étendu :

• Permet de gérer proprement le lazy loading des entités ou collections associées
• Evite d’avoir à merger des entités détachées pour les synchroniser avec la base
• Vous assure de n’avoir qu’une seule référence à un objet pour un id d’entité donné
• Fonctionne avec les mécanisme d’Optimistic Locking pour supporter les unités de traitement à durée de vie longue (l’annotation JPA @Version est très utile pour ce dernier point)

Le persistence context étendu doit donc résider dans un scope stateful, et non partagé. La session ou la conversation pourraient faire l’affaire, mais la gestion de son cylce de vie resterait un peu fastidieuse. C’est pourquoi, la meilleure place pour le gérer est de le placer au sein d’un EJB Session Sateful (Stateful Session Bean ou SFSB).

On ne va pas trop entrer dans les détails des EJB ici (je garde cela pour mon prochain post), il faut juste savoir qu’un SFSB est géré par un container spécifique qui n’a rien à voir au conteneur servlet. Notre Bean a donc un cycle de vie indépendant des scopes servlet mais pourra être manipulé depuis ces fameux scopes soit en étant injecté via @EJB, soit, encore mieux en étant injecté ou directement utilisé via CDI. Le persistence context étendu ainsi utilisé ne sera fermé que lorsque le SFSB sera recyclé.  Nous reviendrons sur tout ça dans un post ultérieur. Pour le moment voici un petit exemple que j’ai emprunté à Adam Bien .

@Stateful
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
@Named
@ConversationScoped
public class OrderGateway{

  @PersistenceContext(type=PersistenceContextType.EXTENDED)
  EntityManager em;

  private Load current;

  public Load find(long id){
    current = em.find(Load.class, id);
    return current;
  }

  public Load getCurrent() {
    return current;
  }

  public void create(Load load){
    em.persist(load);
    current = load;
  }

  public void remove(long id){
    Load ref = em.getReference(Load.class, id);
    em.remove(ref);
  }

  @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
  public void save(){
    //nothing to do
  }
}

La ligne 1 fait de notre classe un SFSB (EJB Stateful), la deuxième ligne désactive le support transactionnel sur l’EJB en question, la ligne 3 fait que la version CDI de cet EJB pourra être utilisé dans une page JSF via l’expression language. Et la quatrième stock le composant CDI dans le scope conversation.

On voit que dans le SFSB on inject un entity manger étendu en ligne 7. Diverses méthodes permettent de chercher, créer et supprimer des entités et en ligne 31 on annote une methode save() avec l’attribut REQUIRES_NEW qui va créer une transaction et la fermer dans la foulée commitant ainsi toutes les modifications effectuées (rappelez-vous l’entity manager empile les  modification jusqu’à ce qu’une transaction lui permette de pousser ces modifications). Ce scénario simplifié permet d’imaginer les possibilités offertes par l’extended persistence context.

Conclusion

L’empilement de technologies masquées par JPA  constitue à la fois l’origine de son succès et la principale raison des critiques que la spécification essuie. Les cas d’utilisations restreints mis en avant par Spring en ne permettant que de concevoir des architecture stateless pour les services, sont également à l’origine de pas mal de galères sur JPA. Pour utiliser cette technologie au mieux je ne vous donnerai que 3 conseils :

• Apprenez Java EE 6, ça ouvre des horizons.
• Si vous ne pouvez pas travailler avec Java EE, utilisez Seam 2 qui marche très bien sur des conteneurs léger type Tomcat et qui reprend ces concepts.
• Lisez la doc de JPA (vous pouvez commencer par ici) et non pas la version Springifiée de celle-ci.

Bibliographie 

Cet Article s’appuie sur les livres suvants

• Seam In Action écrit par Dan Allen
• Java Persistence with Hibernate par Christian Bauer et Gavin King
• Real World Java EE Patterns, Rethinking the best practices  et  Real World Java EE Night Hacks par Adam Bien