Blogounage

Il est possible par programmation de savoir d'où vient une classe : un jar ? un répertoire ? autre ?

Use case classique : vous pensez (et devez) ne plus avoir les commons-logging nulle part dans votre classpath, parce que vous êtes (intelligemment :-)) passés à SLF4J. Malgré cela, il semble que cette fichue classe soit toujours trouvée, mais vous n'arrivez pas à savoir dans quel jar (ou quel répertoire si vous travaillez directement avec les .class). Résultat, ça vous fout un bazar monstre dans la configuration de vos logs. Certains continuent à apparaitre alors que vous avez demandé à ce qu'ils ne soient pas affichés...

Le code est un peu sioux, alors je le mets ici au cas où ça vous servirait :

System.out.println(MaClasse.class.getProtectionDomain().getCodeSource().getLocation());

MAJ du 15/03/2010

Suite à l'incompréhension ci-dessous, voici quelques exemples pour illustrer ce que fait ce code :

Le code :

System.out.println(org.springframework.mail.MailSender.class.getProtectionDomain().getCodeSource().getLocation());

System.out.println(MyJunitTest.class.getProtectionDomain().getCodeSource().getLocation());

Affiche sous Windows :

file:/C:/m2repository/org/springframework/spring-context-support/2.5.6/spring-context-support-2.5.6.jar
file:/C:/tests/myproject-core/target/test-classes/

J'espère que l'utilité est un peu plus claire à présent.

Par le plus grand hasard, pendant la lecture d'un billet de Pascal sur les performances de firefox au fil des âges, je viens de m'apercevoir que je ne profitais en fait pas de TraceMonkey, le compilateur JIT intégré à Firefox depuis la 3.5 !

C'est vrai que je n'avais pas fait très attention, mais que je n'avais pas non plus remarqué d'amélioration notable sur mon navigateur favori. En fait, c'était à cause du fait que j'avais, comme tout bon développeur qui se respecte :-), installé firebug depuis déjà un bon moment.

Sur le blog de Pascal, la phrase suivante m'a donc fait tilter :

Un petit rappel si vous utilisez Firebug, votre moteur de compilation JIT de javascript est désactivé et vous aurez donc des perfs équivalentes à celles de Firefox 3.0, même si vous êtes en 3.5. La version 1.5beta7 de Firebug sortie hier devrait résoudre ce bug.

Aussitôt dit, aussitôt fait. J'ai installé la version 1.5X.0b8 de firebug et j'ai tout de suite vu effectivement une différence. Gmail, Google Reader, Hudson, tout s'affiche plus vite.

Comme j'avais fait le test SunSpider avant la mise à jour, en gros, je peux vous dire que je suis passé de 3500 à 1500 !

Bref, installez-vite cette mise à jour !

Nous gérons en ce moment un petit problème d'intégration avec des WebServices d'une entreprise qui ne s'attend qu'à du iso-8859-1. XML a pourtant été conçu pour gérer plus simplement les problèmes de jeux de caractères et d'encodage utilisé, mais ce qui a été fait ne respecte tout simplement pas la spécification.

En effet, notre code envoie une requête SOAP dans un tube HTTP annonçant de l'UTF-8. Comme ça ne marchait pas, nous avons carrément ajouté l'attribut encoding au prologue XML et retesté avec Soapui, mais ça n'a rien donné.

Alors, comme il faut que quelqu'un corrige son code, j'ai vérifié la spécification^[1], voici ce qui est indiqué :

• Dans le cas où un encoding est précisé en externe, et que le prologue ne spécifie rien, c'est cet encoding qui est utilisé
• Si rien n'est spécifié dans les premiers octets du XML, alors on parse de l'UTF-8 par défaut.
• On trouve aussi cette phrase : All XML processors MUST accept the UTF-8 and UTF-16 encodings of Unicode.

Bref, attendre de l'iso-8859-1 lorsque rien n'est indiqué est au minimum une bizarrerie, et au pire une erreur par rapport à ce que dit la spécification.

When building maven projects with hudson, there's some common best practices about maven repositories handling :

1. isolate maven repositories between jobs
2. regularly purge repositories

The problem

The basic way to do it is to activate the hudson per-job option : "Use private Maven repository". But the thing is you have to do it for EVERY new job you add. There is no way inside hudson to activate it globally.

Documented solution

If you look at hudson help for this option, you'll see a link to a simple solution that specify the repository directly in the maven settings.xml file. The tip is to redefine the localRepository tag inside settings with this special value :

<localRepository>${env.WORKSPACE}/m2_repo</localRepository>

This way, you're done with the first best practice : isolate maven repositories. But not yet with the regularly purge repositories one. Actually, using this option will put the m2_repo inside each hudson job workspace. So, finding and deleting them could become a bit cumbersome. You'd have to cron something like find . -name m2_repo -exec rm -rf "{}" \;.

Even better

As you might have understood, I was not thoroughly satisfied with this solution. I wanted to be able to really easily delete the repositories. So I just changed the option above to have them all inside the same root directory under ~/.m2/repositories, one per job.

Quite simple in fact, instead, just use :

<localRepository>/some/path/.m2/repositories/${env.JOB_NAME}/repository</localRepository>

This way, the only thing you have to put in the cron job is rm -rf /some/path/.m2/repositories/. A bit more straightforward, isn't it?

Hope this helps.

Récemment, SpringSource (Rod Johnson, créateur de Spring) et Google (Bob Lee, coauteur de Guice) lançaient une proposition de JSR visant à standardiser un jeu d'annotations pour gérer l'injection de dépendances.

Cette proposition, « Dependency Injection for Java », est devenue une véritable JSR depuis 3 jours.

Personnellement, j'ai hâte de voir ce qui va ressortir de ce travail. Notamment, je regarderai attentivement en quoi cela complètera ou s'intégrera avec les annotations de common annotations (JSR 250, dont sont notamment issues @PostConstruct, @PreDestroy, @Resource) et éventuellement les annotations de la spécification des EJB3 (@TransactionAttribute, notamment).

Comme la spécification sera développée avec un scm et une liste de diffusion accessibles publiquement, j'essaierai de vous en dire plus à ce sujet dès que possible.

À suivre.

Pour ceux qui n'auraient pas encore vu passer l'information, demain soir a lieu la première session du JUG toulousain. Vous êtes évidemment les bienvenus !

Au programme, GWT et Java ME.

À demain !

Dans les travaux de notre maison actuellement, je me suis enfin décidé à expliquer comment nous avons procédé pour l'abattage de cloisons. Plusieurs personnes ont semble-t-il été étonnées que je n'en parlasse point avant :-).

Abattre des cloisons en brique

Nous avions environ 30 à 40 mètres linéaires à abattre, sur des hauteurs de 2m50 ou 2m80. L'objectif était d'abattre absolument toutes les cloisons, parce que nous n'avions pas de mur porteur (seuls les murs extérieurs sont porteurs sur cette maison). Ces cloisons étaient en brique de 7cm d'épaisseur.

Première étape : se faire une idée de la difficulté des opérations

J'ai commencé par créer un passage entre les pièces pour faciliter la circulation. Ce premier perçage avait aussi pour objectif d'avoir une idée de la vitesse à laquelle nous pourrions abattre le reste.

J'y suis allé franco : à grands coups de masse. (J'avais acheté cette "masse trancheuse" chez Casto. Le côté "tranchant" est effectivement bien pratique.).

Note à ce propos : faites très attention à ce qu'il n'y ait rien qui craigne les projections de gravats de l'autre côté de la cloison sur laquelle vous vous acharnez. En effet, taper à coup de masses dedans a dans mon cas projeté des gravats largement jusqu'au mur suivant (situé à environ 4 mètres). Réfléchissez donc aux fenêtres qui peuvent se trouver derrière, ou simplement aux personnes qui travaillent avec vous. Dans ce dernier cas, hurlez simplement tiiimbeeeer avant de taper, ça fonctionne généralement plutôt bien :-).

Deuxième étape : industrialiser le processus

La technique du "c'est moi que vlà avec ma masse", c'est bien. Mais si vous cassez progressivement et simplement autour du point initial, ça va vous faire des tonnes de gravats à transporter par petits morceaux. Je vous la déconseille donc.

Je vous recommande en effet plutôt une technique que j'ai adoptée ensuite : casser le mur en faisant des grosses saignées pour réaliser des carrés de briques transportables. C'est plus simple à transporter dans la voiture que tout casser en petits bouts...

Pour vous, j'ai testé plusieurs techniques :

1. À la meuleuse d'angle et disque diamant (on l'appelle aussi souvent "disqueuse") : bof. Je vous la déconseille plutôt, sauf si vous avez besoin d'une découpe au millimètre. Mais ATTENTION : si vous partez sur cette technique, préparez vous à faire de la poussière. Mais quand je dis poussière, je ne plaisante pas. La pièce sera remplie de poussière après 5 minutes de meulage...
2. à la masse petit bout par petit bout : vous faites un trou, puis vous l'élargissez progressivement. Cette technique a le gros inconvénient de vous imposer un long et fastidieux ramassage de gravats après coup. Je vous la déconseille aussi. Vous devrez aussi investir à mon avis dans un nombre très important de "sacs de gravats" (j'y reviens plus bas) ;
3. à la masse, avec des saignées pour essayer d'obtenir des plaques de par exemple environ 1m² plus facilement transportables ;
4. à la masse et au marteau, par pan de cloison entier... On part toujours sur le principe des saignées, sauf qu'on part du sol, on va jusqu'au plafond. On fait la saignée au ras du plafond avec escabeau et marteau, puis on redescend jusqu'au sol au bout de quelques mètres. Vous l'aurez compris. Cette technique est de loin la plus rapide. Un conseil toutefois : soyez plusieurs et au moment où vous faites descendre la cloison, retenez la le plus longtemps possible. Par exemple, à trois, nous retenions sans aucun souci une cloison de 2m50 par environ 3m. Pensez aussi à mettre au sol des tapis ou toute chose de ce genre pour amortir le choc de la chute lorsque vous ne pouvez pas retenir jusqu'au bout. Nous avons utilisé cette technique pour les derniers 90% des cloisons sans soucis. Son gros avantage est qu'on peut ensuite simplement récupérer des morceaux de taille assez importante au sol sans trop de petits morceaux.

À propos des petits morceaux, les nombreux "bouts" de gravats que ce genre de travaux va vous produire, un conseil important : achetez des "sacs à gravats" (comme ceux-là). Ce sont des sacs en plastique extrêmement épais qui sont très utiles lorsqu'il faut balayer puis convoyer jusqu'à la déchetterie les bouts de briques cassées sur le sol. Attention, ne les jetez pas avec les gravats... Videz les simplement et réutilisez les jusqu'à ce qu'ils rendent l'âme (jusqu'ici, je dirais que nous avons utilisé chaque sac environ 5 à 10 fois, nous en avions acheté 24...)

Si vous avez des questions, n'hésitez pas.

Dans le prochain épisode, si vous êtes sage : abattre un plafond en plafonnette ou en lattis (oui, j'ai les deux).