07 mai 2009

javax.inject - enfin !

L'injection de dépendance aura marqué ces dernières années :
  • Apache Avalon et dérivés ont montrés la voie, même s'ils étaient sans doute un peu trop précurseurs et largement sous-documentés ;
  • Spring a enfoncé le clou et définitivement imposé l'idée grâce à une documentation rarement égalée dans le monde opensource et aux qualités de pédagogue de son créateur ;
  • Google Guice a marqué une étape en proposant une solution légère basée sur les annotations ;
  • JBoss ne s'y est pas trompé en renommant "sa" JSR299 de Web beans en Java Context and Dependency Injection
sans parler des outsiders que j'oublie probablement... Bref POJO et injection de dépendances deviennent les éléments incontournables de toute bonne architecture moderne. 

Comment éviter d'être lié à un framework donnée ? Via une spécification officielle Java (JSR) !

La JSR299 a cet objectif mais ne remporte pas les suffrages. Ni Google Guice, ni SpringSource n'ont répondu à l'appel ... et on sait enfin pourquoi : Google Guice et SpringSource collaborent à l'élaboration d'une nouvelle JSR, permettant en théorie de passer de Spring à Guice au runtime sans toucher à votre code. 

Malgré ses limitations, j'étais jusqu'ici un défenseur de l'injection via l'annotation @Resource (jsr250). Bien que supportée uniquement par Spring (et les EJB3) elle avait au moins l'avantage d'être non liée à un framework. Avec cette nouvelle JSR, on aura donc un moyen de spécifier clairement l'injection de dépendance sans se lier à un framework et une réelle alternative au runtime. 

Quel intérêt ? Après tout, c'est vraiment rarissime de passer une appli de Spring à Guice juste pour le fun ! Pensez aux frameworks et bibliothèques, qui vont pouvoir exposer leurs composants et dépendances via cette API. C'est déjà le cas pour l'écosystème Plexus, et j'ai développé une passerelle pour pouvoir les utiliser dans un contexte Spring, mais ça reste du bricolage.

A l'avenir, on pourrait donc imaginer récupérer une bibliothèque utilitaire de type "accès à Google Map en Java" utilisant cette JSR et pouvoir l'exploiter depuis Spring ou Guice sans intermédiaire. Un retour des composants de haut niveau "sur étagère" ? 


0 commentaires

06 mai 2009

Un Leopard dans mon XP

Vu que personne ne veut m'offrir un beau MacBook 17 pouces, j'ai bricolé mon bon vieux Windows XP avec un BricoPack pour le rendre "MacOS Leopard-like". La solution du pauvre, c'est vrai, mais c'est mieux que rien.

Découverte intéressante qui en dit long sur Windoz : l'économiseur d'écran "Flurry" en version Win32 est ultra lent sur ma machine - la faute au chipset Intel Graphics. En renommant le fichier flurry.scr en flurry.sCr (subtil !) ça devient tout à fait fluide.

Windoz est vraiment un système étonnant, qui nous promet chaque jour une nouvelle surprise !
2 commentaires
Libellés : ,

compile, compile pas

Je rencontre un problème jusqu'ici innexpliqué sous Hudson :

[INFO] Compilation failure

/home/hudson/.hudson/jobs/bios/workspace/bios/bios-prise-de-commande/bios-pdc-remoting/target/generated-sources/cxf/com/sfr/pates/PaymentQueryManager.java:[26,18] cannot find symbol
symbol  : method partName()
location: @interface javax.jws.WebParam

Je suis tombé sur ce qui semble bien être un bug "rigolo" :

Voici la description de la classe WebParam (définie par la spec JAX-WebServices) sur un poste Windows :
javap -classpath jsr181-1.0.jar javax.jws.WebParam
Compiled from "WebParam.java"
public interface javax.jws.WebParam extends java.lang.annotation.Annotation{
   public abstract java.lang.String name();
   public abstract java.lang.String partName();
   public abstract java.lang.String targetNamespace();
   public abstract javax.jws.WebParam$Mode mode();
   public abstract boolean header();
}
La même commande, passée sur Hudson (Solaris) :
javap -classpath jsr181-1.0.jar javax.jws.WebParam
Compiled from "WebParam.java"public interface javax.jws.WebParam extends java.lang.annotation.Annotation{
   public abstract java.lang.String name();
   public abstract java.lang.String targetNamespace();
   public abstract javax.jws.WebParam$Mode mode();
   public abstract boolean header();
}
Pas de partName :'(

En gros, la librairie de référence jsr181 que j'ai récupérée est bugguée ... D'ailleurs, elle n'est pas dispo dans le repo maven "central" et le lien dans le POM Maven est cassé - il pointe vers leserveur d'un certain "BEA" :p. Délicat donc de savoir où aller la chercher ! 

Il existe heureusement une alternative via les jars du serveur Geronimo. J'ai aussi ajouté dans le build Maven un contrôle sur les dépendances qui permet de vérifier qu'on embarque pas cette jsr181 récalcitrante.

0 commentaires
Libellés :
Inscription à : Articles (Atom)