Le 21 Septembre, le ChtiJUG organise une session animée par Emmanuel Bernard qui travaille pour JBoss sur Hibernate et plus particulièrement sur Hibernate Search et Hibernate Validation.
C’est Norsys qui accueille cette session dans nos locaux de Ennevelin.
Dépêchez vous de vous inscrire, les places sont réservées à vitesse grand V.
La version 1.5 de l’outil de suivi qualité Sonar est sortie aujourd’hui.
J’ai mis en place cet outil sur un de mes projets et je le trouve très pratique, la configuration est très simple et cela permet à toute l’équipe d’avoir une vue à la fois synthétique et précise des marqueurs qualité.
La version 1.5 amène des changements sympatiques au niveau de l’interface graphique et surtout une ouverture vers d’autres outils de mesure via un système de plugins.
Cet article du blog Sonar détaille les principaux changements
Voici un graphique de suivi qualité que l’on peut, par exemple, afficher dans la war room ou sur le site projet.
Sonar est une solution beaucoup plus utilisable que le plugin dashboard maven qui est moins mur.
Dans tous les cas, il faut au minimum que l’équipe adhère aux règles qualité et il est préférable que l’équipe définisse elle même les règles de développement.
La roadmap de GWT 1.6 vient d’être publiée, voici son contenu :
Les évolutions suivantes seront intégrées dans les versions ultérieures :
Après les fragments de GWT 1.6, l’ami Sami nous présente le « Out Of Process Hosted Mode » qui permettra d’exécuter l’application dans le navigateur de votre choix en mode développement et non plus avec l’unique moteur de rendu supporté sur chaque plateforme (Win : IE, Linux : Mozilla, Mac : WebKit).
L’intégration dans les navigateurs se fera à l’aide de plugins qui communiqueron avec la JVM GWT via une socket TCP. A ce stade le javascript se sera pas encore généré et on gardera toujours la possibilité de rentrer en debug dans le code « client ».
Olivier m’a envoyé hier un email pour m’annoncer la sortie de son nouveau projet OpenSource : Appspy.
Appspy offre une solution pour le suivi de vos applications Java coté serveur en production, vous pourrez ainsi consolider toutes sortes de données issues des différentes instances de vos applications et par exemple savoir quelles URLs sont sollicitées, quelles URLs sont lentes ou encore comparer les temps de réponse entre deux versions.
Les applications intègrent un module client qui collecte les données et les fournit au serveur qui permet de les visualiser sous formes de rapports paramétrables. Le tout est disponible sous la licence Apache 2.0 qui est « business friendly ».
Je ne vais pas tarder à essayer cet outil sur un de mes projets, je vous en dirai plus à ce moment la. Ayant eu l’occasion d’utiliser un ancien produit de la même gamme écrit par Olivier, je suis assez impatient
Didier Girard a créé une demande dans le JIRA du projet Spring en vue d’ajouter le support de GWT.
Si comme moi vous pensez que cette cohabitation peut s’améliorer si les gurus de chez Spring se penchent dessus, votez pour cette demande.
A plusieurs occasions, j’ai eu l’occasion de conseiller l’utilisation de Spring JMS car cette API simplifie énormément la manipulation de l’API JMS qui il faut l’avouer n’est vraiment intuitive.
En effet l’API JMS nécessite de manipuler 6 objets (QueueConnectionFactory, QueueConnection, QueueSession, Queue, MessageProducer, TextMessage) pour simplement envoyer un message texte !
Avant de pouvoir utiliser l’api Spring JMS, il faut configurer une ConnectionFactory (Exemple avec Active MQ) :
<bean name="activeMqConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="tcp://theactivemqserver:61616" />
</bean>
Ensuite, il faut récupérer un objet JmsTemplate dans lequel la ConnectionFactory aura été injectée.
Enfin, l’envoi d’un message peut se faire de différentes manières mais un simple appel de la méthode convertAndSend pourra suffir.
Il se trouve que par défaut le JmsTemplate peut limiter les performances des applications car il entraine la création des objets Connection, Session et MessageProducer pour chaque envoi.
La solution peut se trouver du coté du provider JMS qui comme ActiveMQ peut proposer une ConnectionFactory adaptée en gérant un pool d’objets Connection, Session et MessageProducer.
La solution peut aussi venir d’un objet fourni par Spring depuis la V2.5.3 : CachingConnectionFactory cette ConnectionFactory peut encapsuler n’importe quelle autre ConnectionFactory et mettre en place le cache de Connection, Session et MessageProducer.
Dans mon cas, l’utilisation de la CachingConnectionFactory a résolu nos problèmes. Un profiling de l’application avait montré que nos Threads passait leur temps à ouvrir des Session JMS.
Quelques astuces en vrac pour intégrer un projet maven1 (oui, il y en a encore ) dans continuum.
Bruce Johnson, le papa de GWT a annoncé la disponibilité de la version 1.5M1 de GWT.
La version 1.5 est largement attendue par la communauté GWT car elle apporte le support de Java 5 avec les annotations, generics, autoboxing, enums, ….
Attention, ce n’est pas une version stable, elle n’est pas documentée et ne doit donc pas être utilisée serieusement.
Je prépare actuellement une formation au profiling avec JProfiler, j’ai choisi de travailler à partir de l’application Jpetstore, application exemple fournie avec le framework spring. Le tout étant déployé dans un conteneur Tomcat 5.5.25
J’ai inséré dans cette application quelques problèmes à corriger par les stagiaires et notamment une fuite mémoire, j’ai eu la surprise en contrôlant l’efficacité de ma fuite de constater que d’autres fuites étaient présentes.
En effet, certains objets du domaine restent présents dans la mémoire de la JVM et ne sont pas récupérés par le garbage collector . L’application utilise la librairie de tag (taglib) JSTL via l’implémentation de Jakarta, c’est un des tags de cette librairie, le tag forEach qui garde des références vers les objets de la liste parcourue.
En creusant un peu plus, le problème est identifié depuis longtemps dans au sein du projet taglib et au sein du projet tomcat.
En fait le composant taglib présente une méthode qui libère ses données, mais elle n’est pas appelée par le moteur de JSP de Tomcat (Jasper), les deux équipes semblent se renvoyer la balle en expliquant qu’ils implémentent bien leurs spécifications respectives. Le problème est censé disparaître en désactivant le pooling des tags dans tomcat, mais je n’ai pas pu constater d’amélioration.
Tout cela est bien décevant de la part de ces deux projets, je vais essayer de mesurer prochainement le comportement de la fuite dans le temps, est ce que le nombre références augmente ou au contraire plafonne ?.
